RE: [opendx-users] Usage model for OpenDX
Title: Re: [opendx-users] Usage model for OpenDX Hi Matt, I like your approach and Mike's suggestions. His way of embedding OpenDX sounds very nice. As to whether you can use the Image viewer from C calls, I'm not sure, either, because I've never tried running a network through C calls. I recall Pelkie explaining to me that the Image module has a bunch of stuff in it that wrapsother modules like Display and Camera, and I think Image is unduly intimate with the GUI, so it makes sense it might not be available as such, but Mike seems to have a workaround. There is a module in the VPE called socketconnect. I looked and couldn't find it while trying to answer your last message. Glad you found it. It isn't implemented on my dear Windows version, but I looked at the code, and it has a flippin' sweet protocol: 1. integer length of buffer to send 2. the buffer. Then you close the socket. Internally, it treats that buffer as a serialized version of a DX Object and deserializes it. On your client, that means you need to take your data, create a DX Object, and then turn that Object into a string. The command you will use to serialize is Object _dxfExportBin_Buffer(Object o, int* size, void **buffer); It returns NULL on error and your input o on success. I'm telling you about this command b/c I don't recall seeing it in the docs even though it is exported from one of the libs. If you want to implement a shared memory copy, you can start from socketconnect.c. Drew
RE: [opendx-users] Usage model for OpenDX
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
RE: [opendx-users] Re: vtk format in opendx
Hi, VTK's data format is modeled after that of OpenDX. While OpenDX simplifies life by offering positions and connections but represents connections and positions with various space-optimizing techniques, such as IrregularArray, PathArray, and MeshArray, VTK defines separate dataset types for unstructured points, unstructured grids, structured grids, and image data. Just a slightly different approach. The translation should be pretty direct and complete. In order to write an importer, you would write a loadable module. In the HTML documentation, check out the user guide, chapters 3 on the data model and appendix B on file formats. Then look into how to write a module in the programmer's guide. That covers working with positions and connections. The HTML is more recent than the PDF docs. It's some work to get started, but I'm sure you'll be overwhelmedly happy with how rewarding it is to contribute. Also, for VTK, the file format has changed slightly from the main VTK textbook, but you'll pick up on that. Drew -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fabian Braennstroem Sent: Tuesday, April 05, 2005 11:45 AM To: opendx2-users@lists.berlios.de Subject: [opendx-users] Re: vtk format in opendx Hello David, * David schrieb am 05 Apr 2005: Does VTK have a full description of their data format? If so, it wouldn't take much to write and importer for it. David Thanks, it should have. Isn't it a certain kind of structure which I which I wrote? Do you have any hints, where I should look first, when writing an importorter? Maybe, there are any simple examples? Best Greetings! Fabian
[opendx-dev] RE: [opendx-users] OpenDX in a CAVE ...
I guess I'll take this one. There used to be a CAVELib program to render OpenDX, written by Richard Gillilan at Cornell. It used straight OpenGL. It needed only a little work to run, and the code made lots of sense, but it really just translated groups, transforms, and triangles. I have that code and am working a more thorough module to enable Performer to load OpenDX files. It should work with a live link and make it easy to have a direct connection between OpenDX and a CAVE or VR Juggler cluster. I should be done soon, because the professor across the hall needs it and because Pelkie down the hall stops in daily to poke at me with a stick saying, Is it done yet? Drew Dolgert Cornell Theory Center -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, February 01, 2005 5:24 AM To: opendx2-dev@lists.berlios.de; opendx2-users@lists.berlios.de Subject: [opendx-users] OpenDX in a CAVE ... Hello, I've seen mails on these lists in 2002 about people trying to implement OpenDX modules to render inside a CAVE. I would like to know if these projects produced something. Otherwise, is there big lacks of OpenDX to render inside a CAVE through standard libraries like VRjuggler, or CAVElib ? Damien Touraine
