Geomview For Windows?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Early morning musings
For some strange reason, I woke up at 5 am this morning with a bunch of bizarre ideas about what we were talking about last night. Amazingly enough, I still remember them and they still make sense, although not at first glance. Here they are: On closer examination, I don't think that using the level of recursion to decide when to output the interest information will work without a lot of overhead. For example, if you had two functions called (top) and (bottom), with (top) calling (bottom). Now imagine two modules called foo and bar. foo registers interest in (top) and (bottom) while (bar) registers interest only in (bottom). If geomview calls (top), interest data must be sent to foo while geomview is in (top) but not when it enters (bottom). However, data must be sent to bar while in (bottom) since it did not receive the data when geomview was in (top). I think the only way to get the level of recursion thing to work would be to remember at every step what the last level where interest data had been output was for every single pipe. There seem to be two sorts of cascading - the horizontal sort and the vertical sort. Functions calling other lisp functions is the vertical sort and functions causing other lisp functions to be called after the original function has terminated is the horizontal sort. The xform-set command leading to clicks seems like the horizontal sort. At least as far as journaling, I don't think this is that big a problem. I thought of creating two kinds of clicks - a timed click and a forced click. Timed clicks would be the result of xform-set commands and the journal thing would not register interest in them since recording the orginal xform-set command would be sufficient to recreate what was going on. It would register interest in the forced click commands (sent to geomview from modules). I came up with a rather strange solution for the vertical cascading problem. It takes advantage of the fact that when an external module (or geomview itself) sets up the lisp parsar for a command, for example: LDECLARE(("pick", lake, args, LARG_STRING, &name, LARG_HOLD, LARG_FLOAT_ARRAY, inter, &in, LARG_HOLD, LARG_FLOAT_ARRAY, v, &vn, LARG_HOLD, LARG_FLOAT_ARRAY, e, &en, LARG_END)); the parsar does not really mind if more arguements appear than are asked for in the declaration. So it seems like a function set up to take something like (pick Item (x1 y1 z1)) would work without mistakes or error messages if it received the function that came through the pipe actually said, (pick thingy (.1 .1 .1) (.2 .2 .2 .3 .3 .3)) I'm not sure if this is a bug or a feature, but hopefully it will stay around. Likewise, a function meant to take (top x y z) would not care if it got (top .1 .1 .1 (bottom 5)) So in the geomview code (or whereever the functions were actually implemented) each function would look through its interest list and send the following to all of the interested parties: ([function name] [arguements] without a ) at the end. It would then do whatever needed to be done, possibly causing further interest things to be output, but since they would be inside the original set of ()'s, they would generally be ignored. If a program were really nosy, it could probably concoct some scheme to parse them, but it usually wouldn't want to. Right as the function was about to return, it would send to ) to everything that had received the original message. I know this all may sound a bit incoherent, so here's an example: (top) and (bottom) are geomview functions, with (top) calling (bottom). foo, bar, and bat are external modules. foo registers interest in (top) and (bottom) bar registers interest in (top) bat registers interest in (bottom) When (top) is called, foo will receive: (top [top's arguements] (bottom [bottom's arguements])) bar will receive: (top [top's arguements]) bat will receive: (bottom [bottom's arguements]) When (bottom) is called, foo will receive: (bottom [bottom's arguements]) bar will receive nothing, and bat will receive: (bottom [bottom's arguements]) I think this might work a better than various other hacks. There is no way a single command could cause an interested party to receive two independent commands, which was the real problem in the first place. For journaling, one of the main worries was that the script would be filled with large quantities of low-level or meaningless junk. This would not happen in this case since whatever would do the journaling would register interest in practically everything, parse the arguements to each function and ignore the list of lower-level functions which the function called, and spit the function name and the parameters to the script file, eliminating all the info about the low-level function calls along the way. I actually think journaling might work better as an external module if it worked in this way. Another worry is that there would be an unacceptable amount of extraneous garbage being generated. I don't think this is that big a deal; there would be exactely the same number of characters being sent to each external module as there are now. It might make sense to try to keep the amount of stuff generated by the interest statments as low as possible, but that's another problem... The lisp parsar would have to be slightly changed, but I don't think it would be that horrendous. Each function would have to call some interest routine at the start and end of every function, but this still does not seem like that big a deal. I also think doing things this way would be much easier to maintain in the next few months/years than an intelligent journaling mechanism, a level of recursion variable, or some division between high and low level functions. As a continuation of my early morning musings, I cannot resist putting in an advertisement for my favorite hinted-at-but-not-written lisp command. The problem with the two cameras for the stereoscopic view getting in lock step could be solved if you could register inteerest only in the targetcam and then send everything that it did to the not targetcam. The only problem is there is no word to refer to the not targetcam. A while ago I was daydreaming about two functions: one which would return a list of the objects in the world and another that would return the actual name of the target geom. If this two functions could be implemented and extended to work on cameras, I think the problem would be solvable since there would be an easy way to talk to the not targetcam. Ok - that's it. Thank you, gentle reader - I know that was pretty long-winded (just be grateful I didn't start calling everybody when I first thought about this). Anybody have any thoughts? -Celeste
Home | Overview | FAQ | Documentation | Support | Download | Mailing List
Windows? | Development | Bug Reporting | Contributing | Contact Us | Sponsors
site hosted by