Maybe I'll cause some chaos here. No, I *know* I'll cause some chaos here. Note the Image macro is now "polymorphic" in that if it thinks it is running in the javadx server mode it will write images or vrml to file instead of displaying to a window. Image knows about the web environment via inputs to "WebOptions" set by the client applet. So it should be possible to trick any near-vanilla net into writing files by setting the "enable" input of WebOptions to 1 at execution time.
I took a net with Edit...Java...Add Web Tools and saved it to /tmp/whatever.net Then: echo include \"whatever.net\" > whatever grep main_WebOptions /tmp/whatever.net | grep "_in_3 = NULL" | sed -e s/NULL/1/ >>whatever echo "main();" >> whatever cat whatever | dx -script (I did this in /tmp... I see above I'm somewhat lazy about specifying /tmp on filenames) and my former X-window image is now a .gif file of the same geometry. other WebOptions inputs can be used to set various parameters (filename, location, gif vs. vrml) and it is time (past time?) for e.g. jpeg support to be wired in to javadx. Regards, Pete Chris Pelkie wrote: > >I don't care if the image flashes to the screen, so do I still need to bypass > >Image and use Render for memory purposes ? The Camera is always changing > >(calculated according to the footprint of the current swath of data), so > >calculating it once and saving to a file for future runs wouldn't work > >(Chris, > >is this what you meant ?) We wouldn't necessarily need to create images all > >night long unsupervised, so maybe memory won't be such an issue here. > > > > > > That is what I meant, but in your case, it doesn't work of course. If you > do want Image to appear, just hook the object and camera outputs of Image > to Render inputs, then to WriteImage. Yes, you do need to Render a 2D image > object for WriteImage to write. Image does not do that operation. Depending > on your intended purpose, be very very sure you have not grabbed the Image > window and changed its size once you begin the render run or you'll have > different sized images in the output. That's another reason I usually lock > the Camera down (by saving, importing). Most video hardware expects all the > images to be a particular size like 640x480. Quicktime doesn't care what > the size is, but I don't remember what it does if files are different > sizes. So if the Camera is being created by you within the program, you can > send that Camera (changing on each time step) and the current objects to > Render inputs. You can also leave Image running with the same inputs. Then > Image is not inline with Render so you can't screw up the rendered image > size if you do fiddle with Image during the production run. > > Chris Pelkie > Vice President/Scientific Visualization Producer > Conceptual Reality Presentations, Inc. > 30 West Meadow Drive > Ithaca, NY 14850 > [EMAIL PROTECTED]
