From acu44@pop.dial.pipex.com Wed Feb 24 16:36:08 1999 Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by hijinks.com (8.8.7/8.8.7) with SMTP id QAA20284 for ; Wed, 24 Feb 1999 16:36:04 -0800 (PST) Message-Id: <199902250036.QAA20284@hijinks.com> Received: (qmail 18525 invoked from network); 25 Feb 1999 00:35:48 -0000 Received: from userk989.uk.uudial.com (HELO ?193.149.73.57?) (193.149.73.57) by smtp.dial.pipex.com with SMTP; 25 Feb 1999 00:35:48 -0000 Subject: Re: Request for Recap Date: Thu, 25 Feb 99 00:36:25 +0000 x-sender: acu44@pop.dial.pipex.com x-mailer: Claris Emailer 2.0v2, June 6, 1997 From: Charlie Dancey To: "David Handley" , "GNUJuggle" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" David Handley wrote: >1. Dave concedes that there are 2 things to consider about with the >humanoids _mind_. One is the concept of juggling, the other is the physics. >One should exist before the converter and the other afterwards. Excellent, this means that at this point in this message, Dave and Charlie agree about everything they have so far thought about. input -> mind -> physics -> animate -> render Of course this is only my way of writing the scheme, Dave writes it slightly differently, and we could argue about the implementation, but the logical order is, as I understand it, agreed. >2. Dave shows that pre and post engines are actually very similar things. >Pre engines can always be produced as (more complicated) post engines but >the former is not always true. The reason for this is that some default >information is added at this stage but the process is purely mechanistic. >There is a proof for what Dave says but he'll have to be goaded to >re-produce it :o) Here Dave is considering aspects that relate to the logical implementation of the pipeline. I don't disagree with his comments and I'm sure that he can prove what he says he can prove. >3. Dave argues that _delay_ is a feature of a client/server model. What >Dave doesn't say is that if the _delay_ doesn't appear to be enough then a >_delay_ pre or post-processing engine could be written (comment about >flexibility of model required!). When I talked about "delay" I wasn't talking about client/server lag, or technical UNIX issues, I was actually talking about deliberately modelling the human brain's inability to instantly respond to situations or to make instant decisions. I described some simulations in which juggler A had to 'respond' to unexpected moves by juggler B, or when drops occurred. I claimed that juggler A should be coded in such a way as to have a perceptual lag, say two beats, so that juggler A could not magically respond to anything that B did instantaneously. Implementing this by means of taking 'advantage' of the inherent lag of a UNIX based multi-process situation is not a good idea. For one thing GNUjuggle is expected to run on different platforms, so a PC or Mac version is unlikely to consist of separate piped processes. In fact I would expect it to be a single application that implements the 'pipeline' by the commonly used method of heirarchical function definitions. The 'lag' in this implementation is (hopefully) zero. (unless the processing time for each frame should exceed the frame interval in which case any 'live' animation would cease to be possible in realtime.) The client/server model is commonly _implemented_ using UNIX pipes with their inherent lag, but the client/server model is not the _same thing_ as using UNIX pipes. The correct way to implement the perceptual 'lag' of the juggler's mind is to give it a hard value and code it directly. Now in most simulations this feature will not be required, if we are simply setting GNUjuggle to faithfully juggle siteswap sequences and we are not setting it up to 'drop' then the perceptual lag is not an issue. It only becomes an issue when we expect our humanoid to make 'decisions'. In these cases we can simply code the humanoid's decision-making ability on the basis that it cannot take into account certain things unless they happened X beats ago. Hey! We might even have a GUI slider for X. [random thought: sliding X into the negative region would give the humanoid precognition, this would be fine unless humanoid B had the same ability ] >4. Charlie raises issue about the Client/Server model coping with >multiple inputs. Dave says that client/server model can cope and that there >should be 4 input pipelines one for each of: input pattern; humanoids; >props; and worlds. I'm pleased with this answer and knowing Dave he's almost certainly right. Good news. >5. Dave finally says that the input scripts could be interesting for >complex patterns such as passing; however, that shouldn't concern us because >with the pipeline model they can be done down-track. Dave: you are very much focused on the _implementation_ of GNUjuggle are you not? This is of course a Good Thing, but being personally more concerned with the _logical structure_ at this stage I find myself overwhelmed with the finer details of your postings. So to save a lengthy reply to this item, yes, yes and yes. No offense :-) SUMMARY ------- 1: Charlie believes that Dave and he have agreed: input -> mind -> physics -> animate -> render ..though we may use different terminology or divide the pipe under different names. 2: Charlie is adamant that 'perceptual delay' in the humanoid mind should be deterministic (!) rather than resulting from the inherent lag of a particular implementation. 3: Dave has assured us that a client/server implementation is still possible when stages in the pipeline have multiple inputs, so this type of implementation is appropriate for multiple juggler situations (and other complex beasts). POSTSCRIPT ---------- Dave and I (may I speak for you Dave?) are becoming more and more convinced that we are the only people active in this discussion. That's kind of interesting, because we are still both writing as if other people are reading all this stuff. That's quite good for us because if we were simply having a 1 to 1 then we might have given up days ago :-) I think that people probably are skip-reading these postings, but that it is just too much work to absorb the relentless detail that Dave and I are slogging over. So, Dave: I think it would be beneficial to the whole GNUjuggle group for us to take advantage of the high level of agreement we have reached (after all of our esoteric ramblings) and to present to the GNUjugglers a cohesive and totally agreed model of the logical structure of the GNUjuggle pipeline. In think we can do this now. Having agreed on that logical structure we can also show how it subdivides into several distinct stages, each of which can be considered independently [albeit with tight and exact restrictions on the possible types of communication between them]. In this way we will open the door for the other GNUjugglers to devote their attention to the particular stages that their interests and abilities draw them to. Some might like to focus on GUI issues, others on kinematics, others on the design of JuggleScript, and others on considering actual GNUjuggle applications like making our humanoids dance and juggle. Perhaps Dave and I could work on the agreed logical structure for a couple of days outside the group and present our results to the group after that has been done? After all, we've produced a hell of a lot of column inches in the last few weeks and it's hard to see how anybody else could have easily jumped into the argument without having to do a _lot_ of homework first. SUMMARY OF THE SUMMARY ---------------------- 1: Charlie proposes that Dave and he 'wrap up' the logical structure of GNUjuggle and present our results to the group (hopefully in not more than a couple of K). In that way we can say that we have completed Stage 1 of the project. Assuming that our results meet with approval of course. 2: After that, this discussion will hopefully be less onerous and intimidating to all of the other GNUjugglers who have expressed and interest in this project. Everyone can play! Charlie Dancey -------------- "When learning a new trick it's good pshychology to go for a clean finish rather than juggling until you drop. In that way you can finish on a high note, rather than on failure." - Me.