>Hello, all! > >I am trying to write a network that will toggle the Image module's >renderMode property from the network (rather than from the actual Image >window "Render Options" toggle button). So I go into Image an unhide the >renderMode box. When I try to connect anything to it from the network >(rather than "hardcoding" in a value), it runs just fine but if I save it >and then try to reopen later, it won't open in the VPE...won't load to the >point where it displays all the modules on the screen. Still runs okay in >script mode. > >For example, I unhide the renderMode box and connect the tab to a Compute >module that always spits out 1. I can run this network just fine, and it >saves okay. But if I then go to reopen the file (after saving it), it won't >load in the VPE. > >Is this expected behavior, or am I doing something wrong? > >Thanks! > Jeremy Zoss
For what it's worth, I did a quick test on 3.1.4b on SGI Irix 6.2 and did not get this problem (3 module test net). Execute on Change with Selector toggling renderMode works multiple times, Save, open another net, open the test net again, no problem, Executes on Change multiple times. Please keep up the good work on testing the Image bug. I think it's real too. BTW, just for yucks, what color(s) did you try in your test? I have had a client report a bug that I believe is related to image cache problems (in SGI 6.5 openDX 4.0.5 as downloaded, not locally built) in which a ShowBoundary object colored red [1,0,0] creates a weird pattern when you go back in the cache (Undo from later images), but if you change to any other color including [.99,.01,.01], the (visible) problem goes away! (The pattern is a red smear that goes from left to right from the edge of the ShowBoundary). I'm thinking that the pointer indexing of the objects placed in cache is off, which might explain the growing memory leak you've reported. If the Undo referenced the wrong starting point in the Image Cache, it might possibly retrieve an image that would appear messed up but not completely random. I still can't decide if this means the placing or the retrieving is off, though I'd suspect the placing is more likely to lead to a growing memory. It could though be some counter that is being incorrectly incremented and claiming it's using more memory but isn't really, then the counter value is incorrectly being used to build the retrieval offset value, thus returning a bogus image. Another wild-eyed theory is based on the knowledge that in the past, there has been some funny business going on under the covers when DX sees a vector that can be integer, even if you thought it was float. For example, I would think that any RGB vector should be type float and left that way. However, there are (or once were) conditions where the vector [1,0,0] may get internally recast to integer causing untold problems downstream if fed to a routine that demands float (and doesn't reverse the cast). As I say, wild-eyed, but I'm just throwing out a little paranoia that might help us uncover the real culprit. I believe this internal recasting was once seen as an "optimization". (:-) I got as far as some of the frame buffer routines which are "Big Hair" C code (run-on lines with mondo bitwise comparisons, offsets, etc.; easily candidates for the Obtuse C Awards) before getting sidetracked by more lucrative time-wasting activities. What concerns me overall is what fundamental changes were in progress but not sufficiently tested from the time of the relatively stable 3.1.4b and the release of what would eventually have become DX 4.x which is the code base for openDX? In other words, we have to keep in mind that IBM was not planning to pull the plug on commercial development: in fact, I know it was not the decision of the DX group themselves to end development. So we must assume that in the fullness of time, many of these bugs would have been revealed by internal testing or early user testing, and quashed before the release of an official commercial 4.x. Instead, we have to remember that we are now both the testers and the developers. But we are seeing the code base for 4.x, not necessarily for 3.1.4b (although clearly similar or identical in many places). So I ask, can anyone at IBM suggest what sorts of things might have been changed that could have created the Image problems we're reporting that weren't problems in 3.1.4b? Thanks! Chris Pelkie Vice President/Scientific Visualization Producer Conceptual Reality Presentations, Inc. 30 West Meadow Drive Ithaca, NY 14850 [EMAIL PROTECTED] (607) 257-8335 or (607) 254-8794
