[Opensim-dev] Developer Preview Release 0.0.2 Naali and Taiga
This time one year ago we began a long process of re-imagining realXtend as a next-generation virtual world platform (Project Corus: http://wiki.realxtend.org/index.php/Main_Page#Project_Corus). We have set very high goals for ourselves, but a journey of 1000 miles begins with single steps. We are today proud to announce the second milestone in this effort, the developer preview releases of our innovative Naali client viewer, and Taiga reference server. Antti, our fearless figure-head and mascot, has put fingers to keyboard to put up a blog post sharing his thoughts here: http://realxtend.blogspot.com/2009/11/002-preview-release-of-next-generation.html Naali is a modern, BSD-license, cross-platform, component-oriented client viewer; built from the ground up in C++ and Python; using Qt, OGRE 3D, XMPP, GStreamer, and other established, flexible, open source libraries. http://wiki.realxtend.org/index.php/Getting_Started_with_Naali Taiga is our reference server for Naali, leveraging OpenSim and Cable Beach, as well as our own custom extensions, including support for log-in with OpenID, inventory access over WebDAV, server scripting with Python, and mesh-based in-world object. http://wiki.realxtend.org/index.php/Getting_Started_with_Taiga As a developer release, the code is still very much alpha-quality, and only represents a small glimpse of what we intend for the future. It lacks many important features for regular use, and is likely to frustrate anyone not comfortable with debugging a work in progress. We are however hoping that you'll take a look at what we have so far, let us know if anything is not working for you, give us helpful suggestions, or even give us a hand directly by submitting patches. Thank you very much for your continued support and help! ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Developer Preview Release 0.0.2 Naali and Taiga
Beautiful work Ryan! Reading up on it now... -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Ryan McDougall Sent: Monday, November 09, 2009 3:01 PM To: realxt...@googlegroups.com; realxtend-...@googlegroups.com; opensim-dev@lists.berlios.de; kyory...@googlegroups.com; opensim-us...@lists.berlios.de Subject: [Opensim-dev] Developer Preview Release 0.0.2 Naali and Taiga This time one year ago we began a long process of re-imagining realXtend as a next-generation virtual world platform (Project Corus: http://wiki.realxtend.org/index.php/Main_Page#Project_Corus). We have set very high goals for ourselves, but a journey of 1000 miles begins with single steps. We are today proud to announce the second milestone in this effort, the developer preview releases of our innovative Naali client viewer, and Taiga reference server. Antti, our fearless figure-head and mascot, has put fingers to keyboard to put up a blog post sharing his thoughts here: http://realxtend.blogspot.com/2009/11/002-preview-release-of-next-generation .html Naali is a modern, BSD-license, cross-platform, component-oriented client viewer; built from the ground up in C++ and Python; using Qt, OGRE 3D, XMPP, GStreamer, and other established, flexible, open source libraries. http://wiki.realxtend.org/index.php/Getting_Started_with_Naali Taiga is our reference server for Naali, leveraging OpenSim and Cable Beach, as well as our own custom extensions, including support for log-in with OpenID, inventory access over WebDAV, server scripting with Python, and mesh-based in-world object. http://wiki.realxtend.org/index.php/Getting_Started_with_Taiga As a developer release, the code is still very much alpha-quality, and only represents a small glimpse of what we intend for the future. It lacks many important features for regular use, and is likely to frustrate anyone not comfortable with debugging a work in progress. We are however hoping that you'll take a look at what we have so far, let us know if anything is not working for you, give us helpful suggestions, or even give us a hand directly by submitting patches. Thank you very much for your continued support and help! ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] [Opensim-users] Changed default av_capsule_tilted to false in OpenSim master
Hi, 2009/11/10, Justin Clark-Casey jjusti...@googlemail.com: There was a bit of discussion last week in the OpenSim dev's office hour and on irc that changing av_capsule_tilted = false in OpenSim.ini.example would be a good idea in the master branch for avatar related physics for ODE. The av_capsule_tilted=false should generally be safe. Please let me mention some general things to watch out for. These shouldn't be a problem now, but were problems that I encountered and hopefully fixed: 1) Avatar falling through terrain 2) Extremely rapid changes of direction and movement could conceivably cause the avatar capsule to become unstable. Note that these items are refer to poor behavior in terms of the physics engine itself (visualized with drawstuff), as opposed to ways that poor behavior might manifest itself in the viewer (such as bendy-knees). Regarding 1, terrain collisions, reducing the avatar tilt seems to increase the tendency of the avatar to fall through the terrain - this has something to do with the ODE terrain collider, which I wasn't able to fully debug - anyone wanting to give it a shot, let me know. As a workaround, currently a small, experimentally-determined tilt is maintained (even with tilt=false) to prevent falling through the terrain. This isn't ideal, but seems to work well enough. Regarding 2, rapid changing of avatar direction: The tilt rotates with the avatar, snapped in 90-degree increments to one of four directions (NE,NW,SE,SW), so that the direction of the tilt always is opposite the direction of movement. In other words, if your avatar is moving forwards, the avatar is leaning slightly backwards. The reason the tilt is rotated with the avatar is to reduce/remove direction-dependent behavior, such as being only able to climb over prims from a certain direction. The reason the tilt rotation is snapped to 90-degree increments, instead of smoothly rotating with the avatar, is to prevent extremely rapid changes in tilt orientation, which is done by setting ODE motor stops. If you change ODE motor stops too rapidly, the avatar capsule may explode and go flying several hundred meters into the air. Conceivably, if your avatar walked directly straddling a line facing northeast and constantly did a zig-zag motion above and below the NE line, this could cause the avatar orientation to change rapidly enough to cause avatar instability. In practice I doubt that this will be an issue. (Still, would be interesting to write a bot to try to provoke this behavior.) More generally, however, this dynamically rotating tilt is not ideal. I think there are 2 avatar physics issues that need further investigation: 1. Removing the tilt completely instead of just reducing it. Currently not workable because the terrain collider then allows the avatar capsule to fall through sometimes. Fixing this would allow complete consistency (direction-independence) in avatar physics behavior, close avatar interactions like hugging, and no need for changing the motor stops while the avatar is moving, reducing risk of explosion. 2. Allowing flexible height of steps that the avatar can step over. Currently the bottom-most hemisphere of the avatar capsule always drags against the terrain or any objects it collides with. This has the limitation that the height of obstacles that can successfully be stepped over cannot be directly tuned, as it depends indirectly on the size of the hemisphere and the specifics of collision handling (things like ERP, CFM, bounce). Ideally we would want to be able to directly tune the height of steppable objects in OpenSim.ini, or perhaps have this be different per avatar (dependent e.g. on the avatar height). But it looks like we would probably have to implement a new avatar physics mechanism to handle this flexibly: something like a floating capsule, capsule+sphere, or using mesh collisions instead of primitive capsules. -nlin ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
