Jo-Jo

I received a message from Trin about rotating a 3D object using a touch panel. I was going to just send a simple example, but I figured I'd do it publicly--share the wealth, you know. Anyway, Trin, is this kind of what you are trying to do? You notice I just place the camera away from, and looking at, the object, and then I rotate the object with the mouse. I find it easier to do this way. It prevents having to calculate the up vector on the camera, or translation of the object away from the origin. ~Jo-Jo 3DPictureControl.vi

So I was just working on a program where I'm trying to get a bunch of references to stuff, and blah, blah, blah, and I noticed the method Gen C Code Variant, which I'm surious about. I was just wondering, does anyone know what this thing does, or how to use it? The help is not very helpful, I searched here, on NI's forums, and with Google on the internet, but nothing came up. I tried to use it, but one of the inputs is "Config Params," and it's a variant that's supposed to take a "name," and "values pairs." Of course, I don't know what form these are supposed to be in before I flatten them to a variant, or what they do even. Any one have any ideas? ~Jo-Jo

I had realized that I could call the VIs with an invoke node, and then just open and close its front panel, but I wanted to avoid having to load every hierarchy into memory, since it is likely that the end user will only be using two or three at a time (I have seven). In this particular case it won't matter much, as the program I'm writing isn't very large, so I'll probably take your advice. I've written programs before that used a separate VI that kept track of the others, but this has special difficulties of it's own that I wanted to avoid, and I was thinking down the road, if I have a really big distributed app which can't all be loaded into memory at once, how would I do it. The other obvious option is to pass the paths into the seperate hierarchies, so that they can all open their own references, but I'm not sure this is a good idea (I feel like the program resources might start stepping all over each other if I'm not careful). Also, when I spoke about application instances, I believe that I picked that up from some LabVIEW documentation somewhere (or maybe it was here) where it was said that one VI hierarchy is considered one application instance by the garbage collector so even if references are shared somewhere in the hierarchy, when the top-level VI in one of the hierarchy closes, all the references opened in that hierarchy close. ~Jo-Jo

I'm sure I'm not the only one that has run up against this. Does anyone know of a way to keep references alive after closing, or just stopping, the top level VI of the hierarchy that opened them? I'm trying to implement a more distributed architecture (not really distributed in the networking sense, everything is on one PC), in which the different application instances must know what the other instances are doing. In particular when a panel closes, it needs to check to see if any others are open in order to determine what to write to an XML file I am using. I know I can just reacquire new references whenever I dynamically open a new top-level VI, but I feel this is sloppy, and resource intensive. I feel a much better way of doing business is to acquire all the references I need when I initialize the application, and then keep them alive in a global, or something else that allows communication between threads, and close them when I'm finished with them. Unfortunately LabVIEW doesn't like this sort of architecture, and I can't find a way to stop the garbage collection. Anybody have a work around, or do I just have to keep acquiring new references to resources? ~Jo-Jo

Alright, I got it. This is a little counterintuitive, so try to stick with me here, as I'm sure I won't be the only one to run into this problem. So when the camera is translated the target is the point the camera is looking at in the absolute coordinates of the scene. The up direction, however, is the direction the top of the camera is pointing in relative to the camera. To complicate things more, the camera can be thought of as having its own coordinate axes apart from the scene axes, as is ture of every other OpenGL object, which is what the up direction vector uses, but these axes do not rotate with the camera, which is what happens with every other OpenGL object. On a related note, you can get the most amount of control from the camera by making the target a unit vector that moves with the camera, so the camera is always focused a distance of one in front of itself. As an example check out the following setup: If the camera is at the following location: 10,10,10 and it is rotated in pi/2 radians around X axis. The target (using the above unit vector method) will be: 10,11,10 But the up direction will be: 0,0,1 The moral of the story is: Don't think of the target and up direction as two vectors 90 degrees out from each other with their tails at the same point in the same coordinate system. Hope this helps. ~Jo-Jo

QUOTE(TobyD @ Dec 6 2007, 09:47 PM) The solar system VI sets up the camera with the top of the camera parallel to the positive Y axis, and then doesn't move it except with the built-in grabby cursor. What I'm trying to do is move the camera to anything location with an arbitrary orientation. I worked out the math, it is the same as for any object, but the camera does not seem to be responding properly. I have an email into NI. If I hear anything, I'll let you guys know. This method is very important, I can't believe I'm the only one trying to use it, but so far I haven't found anyone who is trying to use it except to establish a static view.

QUOTE(martin@aerodynamics @ Dec 6 2007, 07:07 AM) These help files deal with the built-in camera controller. There is no reference to the method I mentioned in my post. Has anyone here figured out how to successfully use the Setup Camera method? I'm starting to think that it actually doesn't work. I received no response from anyone on the NI developers forum either. I sent an email to NI's application engineers, but I haven't heard from them yet either. I can manipulate the OpenGL camera using C++, and I'm not new to OpenGL, or LabVIEW, (so don't assume that I'm screwing it up in some simple way) but in LabVIEW the only way the give to use the camera is with the Setup camera method, and I have yet to see a demonstration of it working other than putting the camera in a static position with the up direction parallel to the positive Y axis.

QUOTE(JDave @ Dec 5 2007, 11:13 PM) Yes, I'm programming in LabVIEW. The setup camera method is a method of the 3D picture indicator.

So I've been working with the OpenGL stuff for about a year or so on and off, and I have become pretty proficient. There is one thing that I can't seem to figure out, however. I have been trying to control the camera using the setup camera method, and I can't figure out what the up direction is. I thought it described a (unit) vector that pointed out of the top of the camera, but I'm certain that this is not the case, although it seems to be the case sometimes, however in some positions the camera inverts itself. The help files on this method are not useful, which is pretty much the case for most of the OpenGL stuff, unfortunately. Does anyone know how to use this method? ~Jo-Jo