Menu
▾
▴
xvrml-agents — Intelligent Agents for xVRML
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(9) |
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
|---|
|
From: Jeff S. <jso...@gm...> - 2005-10-14 21:15:00
|
Thanks Dave! There is a new drop of Carina in SourceForge with the following changes: - Errors in files now show up as a button in the status bar - Information window on the worlds has been moved to the view menu - Animated gif support added to image textures - Added support for libxslt to convert files instead of using Java - Added open recent menu option - Added basic help system - Bugfix: Commas in vrml files are handled better - Bugfix: Saving of some values in preferences fixed The VRML import, especially from files created by modelers and containing zillions of commas, is much improved. And the best part? Dave has implemented animated GIF support in Carina, so artists get to take the first steps away from building "ghost town" scenes, and the first intimations of movement and dynamicism have entered the arena. As usual, Dave is distributing binaries for Windows and Mac and source tree for Linux. jeffs |
|
From: Miriam E. <mi...@we...> - 2005-08-18 23:36:40
|
Hi folks, I have to go out shortly, so I'll keep this as quick as I can. Interpolators are neat, but they are one of the hardest things in VRML to understand, also they are NOT general purpose. There are some situations where the scene author knows the startpoint, endpoint, and duration of an action, but in *most* situations only two of these will be known, and sometimes not even that. In such situations the poor author has to go through all manner of contortions to make the awfully over-specialised Interpolator nodes work for them. In many, perhaps most, situations the author will have just a startpoint and a force (and sometimes only a force). I'd suggest leaving Interpolators in for backward compatibility, but spend the time working on coupling any VR display system to a physics simulator like ODE. Let the display just display, and let the physics take care of movements. Interpolators have descended from cartooning, but cartoons and VR are quite different things. You can make VR work like cartoons, and for that Interpolators could be useful I guess, but I think most authors would prefer to be able to throw a ball and have it arc up and down to bounce around without explicitly animating it and without needing to know ahead of time where it will bounce to. It is much more sensible to set one force (the wind) against a tree blowing in the breeze rather than having to animate every darned leaf and branch with Interpolators. I have come to the conclusion that building up general purpose animation libraries (walk, run, jump, etc.) that can be easily adjusted to different characters (a dwarf walks differently from a giant, and a pirate with a wooden leg walks differently from either) is next to impossible using Interpolators. In order to develop such general purpose animation libraries we need to use physics simulators. They exist and are free and open source. We should be using them. Otherwise it is like saying the graphics accelerators in video cards exist, but we'll use the main CPU because that is how it used to be done. Simplify and extend. :) Best wishes, - Miriam David Huffman wrote: >>so >>the first question which came up was >>what exactly is in the "key" element? >> >> numbers from 0.0 to 1.0 [representing % of the way through an >>animation]? >> numbers representing absolute (Unix) time? >> numbers representing absolute (since the simulation started) time? >> numbers representing relative (since it was triggered) time? >> something else? >> >>Dave Huffman had some good thoughts about this issue >>which he expressed during the Team meeting this week... >> >>Dave: you want to chime in on this discussion please? > > > the key element is exactly what it looks like, and i think it should stay the way as it was in the original vrml specs. an unbounded set of numbers that are always increasing. realize that a position interpolator has nothing to do with time. it is only a calculator converting a float value to a new position. it shouldnt be a percentage because it may not necessarily just go from start to end. If it is based on time, then it would go from beginning to end like you are expecting. If it was based on something else, like another objects position, it may not go from start to end so simply. > > i believe strongly of keeping the key a float, as it has no connections to time directly. most people connect a time sensor to position interpolators, but it is not always that way, so we must keep it generic. also note that interpolators are not triggered, the sensors such as the time sensor is triggered. > > i believe we have two discussions here, one for the type of keys in interpolators, which i believe should remain generic, and a discussion on how time should be represented in time sensors. a position interpolator has nothing to do with time unless a time sensor is connected as input, and at that point it is only converting an input to output. interpolators can not be time dependent. > > dave -- ---------=---------=---------=---------=---------=---------=------ A life! Cool! Where can I download one of those from? ---------=---------=---------=---------=---------=---------=------ http://werple.net.au/~miriam My live Journal page http://www.livejournal.com/users/miriam_e/ |
|
From: Jeff S. <je...@ar...> - 2005-06-30 03:29:56
|
got yo think on this one a bit more... something is wrong with how I am thinking about it at the moment off to New York City tomorrow back Monday... taking Batya to NYC for a 6-week internship teaching kids in Summer school there she is finishing up an Education grad degree now and it will be a great opportunity for her [although living in "a dorm" is makeing her laugh] ttyl jeffs |
|
From: Miriam E. <mi...@we...> - 2005-06-30 00:45:09
|
Just thinking further on this... If you make force an attribute of other geometry, be aware that more than one attribute is needed to provide all the force info. - the direction and intensity (just occurred to me it can be a single vector) - the point at which it is applied to the object (default to center of mass?) There is no need to specify rotation because ODE would handle that from the force angle, position, and offset from center of mass or IK linkages. That just made me realise that specifying mass alone is not enough. Center of mass is needed too. It would not necessarily be the geometric center of the object. Further thoughts? Best wishes, - Miriam Miriam English wrote: > > > Jeff Sonstein wrote: > >> On Jun 28, 2005, at 11:22 PM, Miriam English wrote: > > >> so you would suggest "Force" as a grouping node? >> >> what about adding (optional attributes with zeros for default values) >> to the grouping nodes themselves? >> this would eliminate adding node(s) to the spec > > > When I originally thought about this some time back I was torn between > making it an attribute or a separate node that was connected to the > things it acted upon via something like routes (though I'd favor direct > coupling rather like the IS in PROTOs). > > The reason I suggested a grouping node for force is that I got to > thinking more about it and realised that a grouping node would let you > put it around all the geometry in a file to act as gravity, or a large > part of a scene to act as a wind, or several objects to act as magnetism. > > I'm still not convinced any of the 3 alternatives is right. Will making > a force attribute be restrictive or inefficient? You can activate a > force attribute on several objects simultaneously and achieve the same > effect as a grouping force, but it requires a lot more explicit > coding... unless the force attribute could be an attribute of existing > grouping nodes. On the other hand orchestrating a series of actions by a > single force (imagine one of those leaf blower machines being waved > around to clear a footpath of leaves) would be very difficult > (impossible?) to program using grouping nodes, and would be best done > via attributes. > > OK. You've convinced me. :) > Force should be an attribute, but not only of geometry, it should also > be an attribute of grouping nodes. > > Best wishes, > > - Miriam > -- ---------=---------=---------=---------=---------=---------=------ A life! Cool! Where can I download one of those from? ---------=---------=---------=---------=---------=---------=------ http://werple.net.au/~miriam My live Journal page http://www.livejournal.com/users/miriam_e/ |
|
From: Miriam E. <mi...@we...> - 2005-06-30 00:08:25
|
Jeff Sonstein wrote: > On Jun 28, 2005, at 11:22 PM, Miriam English wrote: > so you would suggest "Force" as a grouping node? > > what about adding (optional attributes with zeros for default values) > to the grouping nodes themselves? > this would eliminate adding node(s) to the spec When I originally thought about this some time back I was torn between making it an attribute or a separate node that was connected to the things it acted upon via something like routes (though I'd favor direct coupling rather like the IS in PROTOs). The reason I suggested a grouping node for force is that I got to thinking more about it and realised that a grouping node would let you put it around all the geometry in a file to act as gravity, or a large part of a scene to act as a wind, or several objects to act as magnetism. I'm still not convinced any of the 3 alternatives is right. Will making a force attribute be restrictive or inefficient? You can activate a force attribute on several objects simultaneously and achieve the same effect as a grouping force, but it requires a lot more explicit coding... unless the force attribute could be an attribute of existing grouping nodes. On the other hand orchestrating a series of actions by a single force (imagine one of those leaf blower machines being waved around to clear a footpath of leaves) would be very difficult (impossible?) to program using grouping nodes, and would be best done via attributes. OK. You've convinced me. :) Force should be an attribute, but not only of geometry, it should also be an attribute of grouping nodes. Best wishes, - Miriam -- ---------=---------=---------=---------=---------=---------=------ A life! Cool! Where can I download one of those from? ---------=---------=---------=---------=---------=---------=------ http://werple.net.au/~miriam My live Journal page http://www.livejournal.com/users/miriam_e/ |
|
From: Jeff S. <je...@ar...> - 2005-06-29 12:53:45
|
On Jun 28, 2005, at 11:22 PM, Miriam English wrote:
> My suggestion is to leave the interpolators so pre-existing
> work isn't broken [...] but add simpler, more sensible stuff.
I agree
> I'm not sure how to do it in xvrml, but in classic style vrml it
> could be something like:
>
> Force {
> intensity 0.0
> angle 0.0 0.0 0.0 0.0
> at 0.0 0.0 0.0
> children [
> Group {
> ...
> }
> ]
> }
so you would suggest "Force" as a grouping node?
what about adding (optional attributes with zeros for default values)
to the grouping nodes themselves?
this would eliminate adding node(s) to the spec
comments?
> I'd favor adding a mass node or attribute to all geometries.
I agree
interesting discussion...
any other people want to comment?
jeffs
|
|
From: Miriam E. <mi...@we...> - 2005-06-29 03:18:44
|
Hi Jeff and everybody,
Jeff Sonstein wrote:
> On Jun 27, 2005, at 8:18 PM, Miriam English wrote:
>> Currently, in vrml and xvrml there are some fairly arcane animation
>> capabilities (all the interpolator nodes)
>
> this is indeed the next thing in the Project work-plan:
> revise the interpolators
My suggestion is to leave the interpolators so pre-existing work isn't broken (perhaps make its inclusion in viewers optional), but add simpler, more sensible stuff.
>> The only sensible way achieve simple, flexible animations is the use
>> a different, simpler kind of
>> movement: a move command consisting of a force operating upon an
>> object's mass.
>
> so the idea is to simplify the animation declaration in the xVRML code
> and leave more of the how-to-act to the implementation
> [and thus to be spelled out in spec text]
> ??
I'm not sure how to do it in xvrml, but in classic style vrml it could be something like:
Force {
intensity 0.0
angle 0.0 0.0 0.0 0.0
at 0.0 0.0 0.0
children [
Group {
...
}
]
}
The force would be a grouping node and its scope would only cover the objects it groups. This would let the author create things like wind or alternative gravities, etc. The intensity is how hard the force pushes (or pulls if it is negative) and the angle is the direction that the force pushes (or pulls). The at attribute is optional and lets the author focus the action of the force onto a particular point of the object affected by the force (lets you turn an object by pushing it off-center, for instance).
This is just off the top of my head. Somebody else might think of a better way.
I actually hate the children[] attribute so my own choice would not include that, but I displayed it this way for the sake of familiar ground.
> so any given geometry node may have an optional mass attribute set
> and will have a default mass value??
Yes. I'd favor adding a mass node or attribute to all geometries.
It may be that more such qualities need adding later too, so an open mind needs to be kept on the best way to do this. Other qualities that might be useful to have one day could be: elasticity, hardness, tensileStrength, compressiveStrength, viscosity, translucent, conductHeat, conductElectric, magnetic, ferrous, grain...
>> its mass and the IK links to lower- and upper-arm.
>
> ahhhhhh
> there is the "kicker"...
> how to deal with inverse-kinesmatics links
> and their complexity
I'm 99% certain ODE handles IK itself. This simplifies the viewer incredibly.
I should look again just to make absolutely sure.
Best wishes,
- Miriam
--
---------=---------=---------=---------=---------=---------=------
A life! Cool! Where can I download one of those from?
---------=---------=---------=---------=---------=---------=------
http://werple.net.au/~miriam
My live Journal page http://www.livejournal.com/users/miriam_e/
|
|
From: Jeff S. <je...@ar...> - 2005-06-28 11:23:01
|
On Jun 27, 2005, at 8:18 PM, Miriam English wrote: > We need to simplify animation. I agree > Currently, in vrml and xvrml there are some fairly arcane animation > capabilities (all the interpolator nodes) this is indeed the next thing in the Project work-plan: revise the interpolators > they require foreknowledge of the start-point, end-point, start- > time, and end-time of any movement. [...] the same basic problem Dave and others have pointed to > The only sensible way achieve simple, flexible animations is the > use a different, simpler kind of > movement: a move command consisting of a force operating upon an > object's mass. so the idea is to simplify the animation declaration in the xVRML code and leave more of the how-to-act to the implementation [and thus to be spelled out in spec text] ?? > Luckily the pre-existing Open Dynamics Engine (ODE) lets us avoid > most of the work here. > (See http://sourceforge.net/projects/opende/ and http://ode.org/ ) > We just need a couple of > extensions to the (xvrml) language to take the new, simpler move > command: a mass attribute > for objects, and a force. so any given geometry node may have an optional mass attribute set and will have a default mass value?? > With a simplified method of animating objects, moving avatars in > interesting > and progressively more complex ways becomes much, much easier to do. > Now, to specify movement of a hand to an object [...] > All you need is to apply a force to the hand. ODE moves it, taking > into account > its mass and the IK links to lower- and upper-arm. ahhhhhh there is the "kicker"... how to deal with inverse-kinesmatics links and their complexity I'll have to take a look at how ODE deals with this for I haven't a clue it seems to me the danger of increased complexity is raised by adding responsibility for specifying IK is this a false perception? > - One effect is that the walk animation applied to a dwarf will > play differently when used on a giant. > The user doesn't need to alter timings and many intricate aspects > of the animation; it will just run > differently because it is affected by mass. this is indeed part of what I am after > This has wider implications for end-use too. Rodney Brooks showed > how to program robots > using a kind of distributed intelligence, where each leg has its > own "ganglion" coordinating > only loosely with the others. This produces very flexible and > adaptive behavior. Using a > simplified force/mass model for animation in makes it possible to > create simple, open-ended, > cascading animations that are similarly flexible and adaptive. and this is also very desirable thanks miriam this is worth our discussion... but now I have more stuff to read (at ode.org) comments from others? jeffs |
|
From: Miriam E. <mi...@we...> - 2005-06-28 00:18:52
|
Hi Folks, Here are some thoughts for your rumination: We need to simplify animation. Currently, in vrml and xvrml there are some fairly arcane animation capabilities (all the interpolator nodes), but for all their complexity and difficulty to use they are awfully limited. They owe more to traditional cartoon animation than computer simulation because they require foreknowledge of the start-point, end-point, start-time, and end-time of any movement. Usually they need you to set up a timer, associated routes, keyframes and keys to allow for acceleration/deceleration, and a fairly complex script too, but we'll ignore all that added overhead for the moment. How many actions in simulations work that way? Take for example the simplest action of dropping a ball. It is not terribly hard to calculate out beforehand the path it will take, so the vrml-style requirements don't seem unreasonable. Now imagine that you are dropping the ball onto the top of a tree. The ball will bounce from branch to branch, possibly getting stuck at some point, or perhaps eventually making it to the ground under the tree, or even being knocked right away from the tree. Such situations can be difficult or even impossible to precalculate because miniscule differences in starting conditions can make for entirely different outcomes -- the so-called butterfly effect. But even worse, precalculating the action becomes very wasteful. It means you effectively calculate the animation twice; once to precalculate and store all the movements, then the second time to actually perform the sequence. This is very daunting if movements of great complexity need to be made. The apparently simple animation of making an avatar walk to a table to pick up a glass becomes horrendously complex. And forget the hope of building upon them to create slightly altered versions that can be used as parts of even more complex animations. The only sensible way achieve simple, flexible animations is the use a different, simpler kind of movement: a move command consisting of a force operating upon an object's mass. Luckily the pre-existing Open Dynamics Engine (ODE) lets us avoid most of the work here. (See http://sourceforge.net/projects/opende/ and http://ode.org/ ) We just need a couple of extensions to the (xvrml) language to take the new, simpler move command: a mass attribute for objects, and a force. Now we can simply send that data to ODE and let it run the animation, sending updated object data to the viewer program. With a simplified method of animating objects, moving avatars in interesting and progressively more complex ways becomes much, much easier to do. Now, to specify movement of a hand to an object you don't need to give start-time, end-time, start-position, end-position, keys, and keyframe values to each of the hand, lower-arm, and upper-arm objects. All you need is to apply a force to the hand. ODE moves it, taking into account its mass and the IK links to lower- and upper-arm. No further work is required of the world author. If a walk animation is constructed using a series of forces orchestrated in cascading fashion to operate on the limbs of an arbitrary avatar there are a few very nice consequences. - One effect is that the walk animation applied to a dwarf will play differently when used on a giant. The user doesn't need to alter timings and many intricate aspects of the animation; it will just run differently because it is affected by mass. It isn't simply a matter of the giant walking more slowly than the dwarf. The force-mediated animation will do this correctly, whereas it is almost impossible to alter a traditional vrml animation to take account of the differences, because the same thing in vrml uses long, opaque lists of possibly thousands of numbers. - Another result is that modifying the animation or adding to it becomes very simple. Changing a few of the forces, for instance lessening them on one leg, can easily turn a walk into a limp. - Another side-benefit is that natural, lifelike acceleration and deceleration become the norm, unlike the unrealistic, sharp movements that are common in vrml. Smooth movements in vrml require the author to devise complex precalculations of timing for keys and keyvalues. A simple force/mass system requires just forces to be applied. This has wider implications for end-use too. Rodney Brooks showed how to program robots using a kind of distributed intelligence, where each leg has its own "ganglion" coordinating only loosely with the others. This produces very flexible and adaptive behavior. Using a simplified force/mass model for animation in makes it possible to create simple, open-ended, cascading animations that are similarly flexible and adaptive. Such things are virtually impossible if you need both the start-point and end-point of all actions (let alone start-time and end-time, and keys and keyvalues!). More later. Best wishes, - Miriam |
|
From: Jeff S. <je...@ar...> - 2005-06-24 02:03:35
|
thanks to miriam for starting us off... she is also the best 3D avatar artist I have ever known and was very active in the original VNet community and was responsible for making us pay attention to the idea that avatars should be "first class objects" in any virtual environment scheme I'm jeffs and I currently teach in the Info Tech Department at RIT [in upstate New York... brrrrrrr] I "got hooked" by computers in the early 70s working with punch-cards on an IBM 360 using SPSS and a "Ten Statement FORTRAN" book about WATFOR in the 80s I was a social service bureaucrat in Oregon and in the 90s I was a secret PoV-Ray nut working at New College of California in San Francisco... I read a little sidebar mini-article in a magazine with really ugly layout and colors called "Wired" about how they had started hosting a mailing list concerned with putting 3D on the Web... I joined the list and I put in my $0.02 about the spec and the process from time to time I was a member of the VRML "DataBase Working Group" I maintained a site and model repository I called "the vrmLab" I hacked a little of the VNet code I hosted a VNet world or two and I hosted and maintained the vnet-interest mailing list I was at NASA-Ames for a while in the late 90s working on a collaborative engineering project and then got hired by Blaxxun and was their rep to the Web3D Consortium's "Contributors Group" working on the next generation for VRML... I wrote one of the first "straw man" DTDs for a proposed shift to XML and contributed to the beginnings of the X3D DTD and spec... I pushed for consideration of Schema rather than DTD as the definition asserting that people needed to be able to read the stuff and that the structure offered by DTD was not good enough without the constraints and rich assortment of data types added by using Schema I've been somewhat of a thorn in some people's sides for insisting for years that the X3D DTD and the Schema they began auto-generating from it both be well-formed *and* both be demonstratively valid [and yes, they both still fail validation tests] I left Blaxxun and came to RIT in the Spring of 2000 but continued on the "Contributors Group" mailing list for 2 or 3 more years... I gave up in 2003 and began the xVRML Project to come up with a more-or-less simple evolution of VRML97 to a human-readable XML form... with a bit of learning from the VRML content creator experience thrown in and looking back to the original VRML goals [including MU in the original draft vision by Tony Parisi and Mark Pesce and Gavin Bell] and looking back at the VNet experience I am a fan of learning from my own and other people's experiences so that I can make *new* mistakes oh yeah and just to confuse things further I'm not a grad-school-trained computer scientist I'm a grad-school-trained psychotherapist... but I keep ending up making my living hacking code so life goes <grin/> you can find my RIT academic webspace at: http://www.it.rit.edu/~jxs/ you can find my personal webspace at: http://ariadne.iz.net/~jeffs/ and you can find the xVRML Project at: http://www.xvrml.net/ ttyl jeffs |
|
From: Miriam E. <mi...@we...> - 2005-06-24 00:20:36
|
Hi all, Just a little intro to those who don't already know me. My interest in VR dates back to the sixties when I was a school kid and the only computers were giant mainframes. Much later, on my old TRS-80 and CoCo and Amiga computers, I wrote and fiddled with 3d programs, but I'm really not really much of a programmer -- I'm mostly an artist and a small-time writer. For a long-time I've inhabited the www-vrml list and have been doing vrml since late 1996. I became impatient at the lack of progress after vrml stalled at version 2.0/97 and the stagnation resulting (as I see it) from formation of the consortium -- an unfortunate consequence that nobody could have foreseen. Nowadays I just lurk there. Some time back I spent a fair amount of time running an ActiveWorlds world for kids for the Australian government and built a moderate amount of RWX models for it. I've also created some MicrosoftAgent animations. I recommend that anybody interested in high-level animation look at MSAgen ts -- they have a simple, but powerful action system very similar to the ActiveWorlds avatars'. My interest in 3d languages remains very strong, but I have to admit I never "got" the attraction of xml for 3d. :) For me, the idea of a simplified and extensible language for animating things (not only avatars, but leaves of trees, bouncing balls, vehicles, etc.) is not only intriguing, but a requirement if we are to build large, complex worlds. We need to be able to extend and build upon what others have done before us, otherwise we all constantly start at the beginning. At the moment, in vrml, if someone wants to animate something, they can't take something that they or another person has done and improve it or bend it to their new need; they have to start each time from scratch. There is no possibility for any kind of vrml animation community because nobody can learn from anybody else. Such progress requires some kind of animation language (preferably one that can be extended). Then exchange and cross-fertilisation can bring real growth, and gradually more interesting and useful creations. Another side-benefit is that it would also be far more efficient than the current large, obscur e wads of numbers that must be sent for vrml animations. Okies. That is where I'm coming from. Later I'll give some idea of what I mean by an animation language. What its elements might be, and how we might make it extensible. Finally I'll give my suggestions of what it would be nice to eventually have -- what direction I think we should be aiming at. Please don't feel I'm trying to direct the discussion. I'm not. I just want to show my interest and begin the conversation. Please don't hesitate to point out my mistakes and show where I might be barking up the wrong tree. Best wishes to you all, - Miriam -- ---------=---------=---------=---------=---------=---------=------ A life! Cool! Where can I download one of those from? ---------=---------=---------=---------=---------=---------=------ http://werple.net.au/~miriam My live Journal page http://www.livejournal.com/users/miriam_e/ |
