Re: [Opensim-dev] Avatar sinking into the terrain
On 16/07/12 10:52, Oren Hurvitz wrote: I want to bring up again the problem of avatars sinking into the terrain. I strongly believe that to properly resolve this, better physics visualization is needed to visualize the internal data structures (the terrain and the physical avatar capsule). There was some code available that would display the physics world as ODE sees it in real-time, but when I last worked on this (years ago) I think the terrain wasn't visualized. If the code is still as I last left it, then the avatar capsule orientation is still rather hacky in that it is always tilted. A straight-up capsule should theoretically have worked fine, but it didn't (falling through the ground very frequently), and apparently a tilted capsule, while better, also doesn't always work. I remember being able to reproduce the problem (a collision should have been registered, but wasn't) and investigating the in-memory structures of the terrain collider, but I didn't have time to find the root cause. Though I'm not actively working on OpenSim these days, this still bugs me, as I feel I was close to the solution but didn't quite get there. To really get to the root cause, I would recommend implementing some sort of collision logging, visualization, and forward/backward stepping through the log file to see what collisions are happening at each timestep. Then find a specific geometry that can reliably reproduce the bug and determine where the missing collisions are occurring (times when the avatar capsule is geometrically intersecting the terrain - which must be confirmed in the visualization tool previously mentioned - yet ODE failed to report a collision). Then, trace through the capsule-terrain collider to see why the collision was not produced. It would be a fun endeavor for me but my hands are full with other projects right now. :( -Norman (nlin) ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Leaving Project
2009/11/23, Frisby, Adam a...@deepthink.com.au: The big problem here is there's a very real lack of viewer developers in this community - there is some overlap between server network engineers (like the OS community) and 3D Viewer Developers here, but not much. If we do have 3D devs in the community who haven't done anything and feel like contributing - you really should be talking to some of the 'next gen viewer' projects and seeing if we can get something awesome done faster. Hear, hear :) As far as I know there are three viewer projects that are written in C#, so those would be a good opportunity for interested C# OpenSim developers to contribute. The three that I know of are Looking Glass, IdealistViewer, and Rei (based on IdealistViewer). Rei also has a plugin architecture similar to OpenSim, and can be controlled with JavaScript, so extending the viewer is rather easy. All three of these C# viewers would be candiates for OpenSim developers to work on without worrying about code taint issues that might arise when looking at GPL viewer code. You don't necessarily need to have extensive 3D graphics knowledge to contribute, because 3D graphics is only a small part of the code; the rest is similar to what OpenSim is doing (receiving/processing/forwarding data). -nlin ___ 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
[Opensim-dev] Answering some questions about 3Di Viewer Rei
Hi, Great to see the interest in and discussion around the open source 3Di viewer Rei. As for some of the questions that have been raised, let me try to address them here. 1. Upstream OpenSim: Rei works with upstream open source OpenSim. We have several reports of it being used successfully, so please let us know if you have problems getting it running. There are probably bugs, and we'll be working on fixing those bugs. If you find some bugs, please post them to our public bug tracker on github: http://github.com/3di/3di-viewer-rei/issues 2. 3D Meshes: We are very interested in working with the community to continue the ongoing discussion about how to get meshes working in upstream OpenSim. The 3Di commercial product 3Di OpenSim Enterprise has implemented a specific mesh solution that depends on Irrlicht-format meshes, because our rendering engine and content tools are based on Irrlicht. However, Irrlicht-format files are probably not going to be usable in viewers that aren't based on Irrlicht. So the next step is to continue discussion about community needs, to find a general, standard mesh solution for OpenSim. 3D meshes are just one example of new content types that can be implemented when compatible licenses allow developers to work both on server and viewer. I'm sure there are many other more exciting things that are possible. Thanks, -nlin ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] 3Di Viewer Rei goes open source (BSD licensed in-browser viewer)
Hello, Today 3Di's in-browser viewer source code has been opened up, as the project 3Di Viewer Rei. The license is BSD. Please have a look if you are interested! Project home page: http://3di-rei.org Press release: http://3di.jp/en/news/2009093001.html We're very interested in further development of this open source viewer with the community. Thanks to the IdealistViewer developers, as portions of Rei use source code from an early version of IdealistViewer. Rei uses no code from GPL-licensed viewers. The Rei source code is in git at github, with the main repository at: http://github.com/3di/3di-viewer-rei Thanks, -nlin ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] Avatar physical capsule tilt in ODE, Mantis #2905
Hello people, I was investigating some physical avatar behavior with ODE and managed to fix the avatar capsule tilt that causes Mantis #2905 to occur and also causes other inconsistency in avatar movement (e.g. sometimes not being able to pass through thin passages). However, I noticed that the fixing the capsule tilt seems to cause the avatar to sink into the terrain if the slope is steep. I suspect that there may be some fudge factors in the physics code that were tuned to work with the leaning capsule which may need to be re-tuned, but I am not sure at this point. Removing the capsule tilt results in a consistently-behaving, straight-upright capsule. Even though this behavior is on the whole preferable, it may cause some hiccups for anything that was tuned to work with the old leaning avatar capsule. I was planning on going ahead and committing this patch. To avoid breaking anything that depends on the current behavior I will add an option to OpenSim.ini in the [ODEPhysicsSettings] section, something like av_capsule_tilted = true as the default with no change in behavior, and false as the corrected but not yet thoroughly verified mode. If no problems arise, we can later change false to the default. Any objections? Thanks, N Lin (nlin) ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] mantis resolved vs. closed
Hello, One possible source of confusion is that the OpenSim wiki says Please leave closing of bugs to core team. A closed bug means we think it's gone forever, or the bug report is invalid. (http://opensimulator.org/wiki/Bugs) That may explain why lots of issues remain in the resolved state. Is the wiki statement no longer valid? -nlin 2009/1/26 Nebadon Izumi nebadon2...@gmail.com I always saw it as that when a developer or someone marked a ticket as resolved it meant they made an attempt to resolve this item and that the filer needs to test it and either close the ticket or re-open back to a true bug status, and only the reporter should close the ticket, that is until a certain amount of time passes then either a manager or developer should close the ticket as they see fit. Hope this helps. Nebadon ___ 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] Vehicles in Opensim
Hello, LSL vehicle scripts currently won't work as-is, since the vehicle-related functions are basically stubs for now. Also, since OpenSim is using a different physics engine back end than SL, it's unlikely that 100% compatibility with LSL vehicle scripts will be achieved any time soon, if at all - at the very least, vehicle parameters would need to be tweaked, preventing use of existing scripts as-is. Some people have had good success - apparently better than with the original SL vehicles - implementing vehicles by setting forces directly via LSL. Another option, that can be combined with this, is to use joints to directly model rotating wheels. See the OpenSimulator wiki page on NINJA_Physics for more information on this latter option. Thanks, N Lin (nlin) 2009/1/15, Ai Austin ai.ai.aus...@googlemail.com: the LSL is all going very well indeed, thanks to the developers for all the work on this. Many scripts I bring over from SL work fine first time now. But my vehicle scripts simply give a compile error saying wrong script engine in use. I am using physics = OpenDynamicsEngine meshing = ZeroMesher physical_prim = true DefaultScriptEngine = ScriptEngine.DotNetEngine I tried switching to XEngine, but then many scripts failed to compile, so I assume its not as mature in terms of LSL support? The region XML files have some new (default written) entries in them that might affect this? nonphysical_prim_max=0 physical_prim_max=0 clamp_prim_size=false object_capacity=0 ___ 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
