Re: [Opensim-dev] database fields names
-1 As someone who has several external modules and knowing of several different external projects that directly access the database, the names should not change. I'd bad enough with Justin 'cleaning up' public interfaces of OpenSimulator classes. While strange naming is irritating and would be cleaner if modified, don't change things just to make them prettier. -- ra From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of ssm2017 Sent: Friday, October 25, 2013 6:23 AM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] database fields names hello what do you think about the idea to take the opportunity for 0.7.8 to unify the database tables names ? for example, the uuid of a user in UserAccounts is PrincipalID, in the Presence table, this is UserID and in auth (without capitalization) this is UUID... ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Feature Proposal: BulletSim GPU Acceleration via OpenCL
OpenCL libraries do provide speedups even on non-GPU systems. Designing the application for OpenCL causes data structures to be built to be parallelizable. Most processors have some form of wide instructions (SSE, etc) that can use the parallelizable data. Multi-threading can also be applied to the operations. Even existing system could see some speedup. -- ra -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of R.Gunther Sent: Tuesday, September 10, 2013 10:36 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Feature Proposal: BulletSim GPU Acceleration via OpenCL A quick reply, i see one problem. most of the servers (inlcudeing mine) dont have realy openCL support. So not sure what benneifit you want to get from openCL if the GPU dont support it. On 2013-09-10 19:30, Sean McNamara wrote: Hi, all. I think my proposal mostly speaks for itself, so I won't belabor the point in this email. Suffice it to say, if you are interested in performance of OpenSimulator, and in particular physical objects performance, please check out my feature proposal here and provide feedback, either by editing the page directly or replying to this email. http://opensimulator.org/wiki/Feature_Proposals/BulletSim_OpenCL Thanks! Sean McNamara ___ 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 ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Feature Proposal: BulletSim GPU Acceleration via OpenCL
I (the main worker on BulletSim) will edit the proposal page but, I will say, the main reason I chose to work with Bullet was for its promise of having hardware acceleration. There have been versions of Bullet that use Cuda and OpenCL and I did some early testing. Erwin has been teasing Bullet 3 for a few years now which is supposed to have real OpenCL support. While not stated explicitly anywhere, my wish is for eventual complete parallel physics support -- both multi-threading and OpenCL. -- ra -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Sean McNamara Sent: Tuesday, September 10, 2013 10:31 AM To: opensim-dev Subject: [Opensim-dev] Feature Proposal: BulletSim GPU Acceleration via OpenCL Hi, all. I think my proposal mostly speaks for itself, so I won't belabor the point in this email. Suffice it to say, if you are interested in performance of OpenSimulator, and in particular physical objects performance, please check out my feature proposal here and provide feedback, either by editing the page directly or replying to this email. http://opensimulator.org/wiki/Feature_Proposals/BulletSim_OpenCL Thanks! Sean McNamara ___ 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] I need a small favor - add bulletsim log to OpenSim.exe.config
If you would like the regular OpenSim.log entries for BulletSim to go into a different file or to happen at a different log level, there are examples for that in the existing bin/OpenSim.exe.config. Probably, an addition similar to: logger name=OpenSim.Region.Physics.BulletSPlugin.dll level value=DEBUG/ /logger You can also add an appender-ref to this logger section to have the log messages go into a different file. So, extend the example you gave with another logger section that specifies the BulletSim DLL as the 'name'. BulletSim has its own VERY DETAILED logging that outputs all the gritty details of operation to separate log files. This logging is enabled from your INI file with: [BulletSim] PhysicsLoggingEnabled = True PhysicsLoggingDir = . ; can be set to any directory VehicleLoggingEnabled = False; set to 'True' to also get messages on vehicle computations To understand the output of the detail log files, you will need to refer to the sources. -- ra -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of OpenSimFan Sent: Wednesday, July 31, 2013 5:50 PM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] I need a small favor - add bulletsim log to OpenSim.exe.config I need a small favor. I want to add bulletsim log to OpenSim.exe.config as a separate logfile for debugging, but not sure how.. please help here is mine OpenSim.exe.config https://dl.dropboxusercontent.com/u/37745116/OpenSim.exe.config maybe add this as a .example to git master... Thank you.. - _ Keep up the good work.!!! - OpenSimFan My Opensim/Second Life Blog http://verwijs.wordpress.com (Dutch, basic hardware/software help windows, Mac, Linux) http://verwijs-pc.nl My Twitter Page: http://twitter.com/OpenSimFan My Facebook page (be my friend, please ) http://www.facebook.com/andre.verwijs -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/I-need-a-small-favor-add-bulletsim-log-to-OpenSim-exe-config-tp7578687.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ 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] Running BulletSim on osx
The BulletSim build process is to generate static Bullet libraries and then statically link these to create the BulletSim DLL/SO. The CMake parameters I use are “-DBUILD_EXTRAS=on –DBUILD_DEMOS=off –DINSTALL_LIBS=on –DINSTALL_EXTRA_LIBS=on –DBUILD_SHARED_LIBS=off –DCMAKE_BUILD_TYPE=Release”.[1] The shared library build is ‘off’ to generate the ‘.a’ libraries to statically link with BulletSim. If you come up with a similar build process for osx, I would like to add that to the BulletSim documentation so, when you are successful, please share the process. A totally different approach would be to use the Bullet implementation that is all C#. This requires no machine dependent libraries at the cost of some performance. This other engine is turned on in your INI file by selecting the BulletSim physics engine and then specifying the XNA Bullet implementation: [Startup] physics = BulletSim [BulletSim] BulletEngine = “bulletxna” -- ra [1] BUILD.TXT for BulletSim in opensim-libs with recently updated with the CMake parameter examples. From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of jon cundill Sent: Tuesday, April 02, 2013 4:25 PM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] Running BulletSim on osx Does anyone know what steps are needed to get this working? I've been trying to enable BulletSim physics for osx. The dylibs aren't in git - so it doesn't work out of the box, but I've been playing around this evening trying to get this running on my mac. I've managed to get the opensim-libs cmake working for osx lion (at least I think I have - cmake -DBUILD_SHARED_LIBS=ON -DFRAMEWORK=ON etc, gives me a bunch of promising looking shared libraries) and I've found the code that tells the bullet Physics config how to look for the appropriate dylib in lib/lib32, so I can fix that up as well. However, nothing called libBulletSim.dylib seems to get built by the cmake files in opensim-libs, so I'm a bit confused as to what binaries I would need to copy into the opensim lib folder in order to make bulletsim happy. Do I simply rename libbulletcollision or libbulletdynamics to libBulletSim, or is it a bit more involved than that? Thanks jonc ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Avination's Physics vs. BulletSim
I'm not totally sure the context for this. There are many pieces involved in physics. The last addition by Avination was the plumbing connecting the physics parameter dialogs in the viewer to the SceneObjectPart and eventually to the PhysicsActor. This included protocol, client stack and SOP code to get the friction that is set in the viewer dialog all the way to the physics engine. Since these additions, BulletSim has been updated to use the user set friction, etc values. So, the changes made BulletSim even better and makes overall OpenSimulator better. -- ra -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of drWhiet Sent: Monday, February 11, 2013 8:01 AM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] Avination's Physics vs. BulletSim Hi all, I just wonder how Avinations decision to contribute their physics back to opensim affects the development of BulletSim. Will both exist next to each other ? Mayby Adam can say something about this ? Best regards, Wordfromthe Wise ___ 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
[Opensim-dev] BulletSim office hours: Tueday January 29nd 8am PST
Bring your vehicle expertise and vehicles you would like to debug to the BulletSim Vehicles Office Hour which is held every Tuesday at 0800 PST (8:00am PST, 1600 UTC) in the BulletSim region in OSGrid[1]. The next one is tomorrow Tuesday January 29nd. See you there. -- ra ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Dynamic attributes
This implementation will work for physics. The physics engine cannot reference Scene (circular reference madness) so, on creation of the scene's physics instance, I will pass in the instance of DAMap (since it is defined in OpenSim.Framework) much the same way the asset request method instance is passed in. I am +2 on this branch's inclusion into master. -- ra -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey Sent: Friday, January 25, 2013 5:14 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Dynamic attributes On 25/01/13 08:40, Oren Hurvitz wrote: Ok, great. I hope all goes well and this will be added to master soon. What do you mean by put the code in for MSSQL? The code already supports MySQL, MSSQL and SQLite. Apologies - my brain stored the assumption that only MySQL had been added since that's the only one I remembered seeing in the commit summaries but I see that the MSSQL code is there. -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc ___ 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
[Opensim-dev] BulletSim office hours: Tueday January 22nd 8am PST
Bring your vehicle expertise and vehicles you would like to debug to the BulletSim Vehicles Office Hour which is held every Tuesday at 0800 PST (8:00am PST, 1600 UTC) in the BulletSim region in OSGrid[1]. The next one is tomorrow Tuesday January 22nd. I have started some BulletSim pages on the OpenSimulator Wiki. Checkout the listing of functions supported by BulletSim at http://opensimulator.org/wiki/BulletSim/Functionality where I will update what is working and not working in BulletSim along with some additional commentary on vagaries of the functions. There have been improvements in vehicles. I have been creating test scripts and running them in SL and in OpenSim/BulletSim to compare the physical effects. This has led to some changes to the vehicle functions. For instance, vehicle turning is now different than ODE but more like SL. The vehicle functions that are not working yet are the angular functions (banking, vertical attraction, deflection, ...). Work is progressing thereon. The new function osGetPhysicsEngineType() will return BulletSim for your scripts[2]. If 'os' functions are enabled in the region, this function will not throw an exception if permissions don't allow execution. It will just return an empty string. Be sure to lobby for 'os' functions to be enabled by default and for this function in particular to be enabled by default for all regions. Some Manti have been closed: Mantis 6481: BulletSim - llMoveToTarget does not work (http://opensimulator.org/mantis/view.php?id=6481) Fixed Mantis 6473: bulletsim - avatar floats after standing up Fixed Mantis 6040: Vehicle linear motor is projected onto the region global XY plane Fixed for BulletSim although ODE still has this problem. -- ra [1] My networking guys assure me that networking is really, really fixed this time. [2] OpenDynamicsEngine is returned for ODE. It is actually returning whatever was in the INI file specifier physics = XXX. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] IRegisterInterface for extending scene entities
I have a need to add more attributes to an SOP (use specified center-of-gravity, user specified mass, rolling friction, ...) and the implementation of Justin's dynamic attributes is just what I need. It does not fulfill my other wishes of adding functionality to SOPs, but it does allow the dynamic addition of new and serialized objects attributes. Can we Just Do It(r)(tm)(sm)? Some comments in the code suggesting a top level naming convention (prepend attribute names with your module name or some such) and an admonition to not store large things might be sufficient to control the use of a simple OSDMap. What do you say? I am +1. How about everyone else? It is a start. -- ra -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey Sent: Friday, January 04, 2013 5:18 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] IRegisterInterface for extending scene entities No problem in making this e-mails, Robert - I think this is exactly the kind of discussion that we need. These are the kind of decisions that we'll be stuck with for a long time so I think we need to think them through, both through discussion and review or proof-of-concept code. I hadn't really properly considered that the JSONStore is close to this. I suppose one other significant difference is that the current dynamic-attributes effectively stores data per part rather than through a single datastore for the whole region. But even if it does use the blackboard pattern, there still has to be an underlying persistence store, which in this case would be a serialized JSON object that is functionally identical with the OSD Map (I've run out of time today to see if the JSON store enforces type safety in some way). Really, the code could be very similar, though in terms of formats I would prefer if to avoid further schizophrenia over data storage in OpenSimulator. If we stored as JSON, for instance, we end up transporting a JSON object in XML... :p On 04/01/13 21:22, Adams, Robert wrote: I think adding a module allowing scripts to attach dynamic variables to SOPs is the right level of functionality. Just adding a key/value store is way too low a level. For instance, the JSONStore module (http://opensimulator.org/wiki/JsonStore_Module) creates a dynamic variable storage to share between scripts. Since it's made for sharing, a script can request events when values are updated. The module adds, as one piece, functionality for extension and communication between scripts. Does this attribute store enable such? Would a script want to know when one of the key/value pairs changed? Is polling suitable? Does the usage case just need static variable addition? As to the practical, implementation angle, yes, you are correct that adding an OSD store on a scene object is simpler. This is an open source project, after all, so this is just my opinion. -- ra -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Oren Hurvitz Sent: Friday, January 04, 2013 11:22 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] IRegisterInterface for extending scene entities The typing problem is already solved since the dynamic attributes are implemented using OSD. Your proposal is much more complicated than the currently proposed attributes, and I don't want to suppress a good solution in favor of a perfect solution that might never be implemented (I assume you're too busy with BulletSim to do this...) Furthermore, it would prevent a very exciting use-case: the ability to use dynamic attributes from a script, using OSSL. (Well, unless you add a module for that specific purpose, but in that case you just added a layer of indirection around the key-value store.) Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/IRegisterInterface-for-extend ing-scene-entities-tp7578406p7578425.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ 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 -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc ___ 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] multiple robust instances
= OpenSim.Services.HypergridService.dll:UserAgentService InGatekeeper = True [Messaging] OfflineMessageURL = http://beta.francogrid.org/grid/services/offline-messages ForwardOfflineGroupMessages = true *** 2013/1/14 ssm2017 ssm2...@gmail.commailto:ssm2...@gmail.com there is no stack trace and all the rest of the console output is clean and the grid is working :) i only have one red line that is this one but maybe i have made a mistake in the robust configuration with my myltiple instances 2013/1/14 Adams, Robert robert.ad...@intel.commailto:robert.ad...@intel.com If you are lucky, there is a stack trace after that error in the OpenSim.log file. Creating a Mantis entry with that stack trace would help pinpointing the error. -- ra From: opensim-dev-boun...@lists.berlios.demailto:opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.demailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of ssm2017 Sent: Sunday, January 13, 2013 3:48 PM To: opensim-dev@lists.berlios.demailto:opensim-dev@lists.berlios.de Subject: [Opensim-dev] multiple robust instances hello using 0.7.5-rc1 under a debian 6 with mono 2.10.8.1 i have separated robut on 3 parts : grid/assets/inventory following this procedure : http://opensimulator.org/wiki/Configuration#Running_multiple_ROBUST_service_instances everything looks working but i see a non blocking error when i start the grid robust instance : Error loading plugin OpenSim.Services.Interfaces.IAssetService from OpenSim.Services.AssetService.dll. Exception: Object reference not set to an in stance of an object any idea about what it could be ? if there are any errors on the wiki page, is it possible please to update it ? ___ Opensim-dev mailing list Opensim-dev@lists.berlios.demailto: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
[Opensim-dev] BulletSim office hours: Tuesday Jan 14th 8am PST
[Resend since it didn't seem to go anywhere the first time. -ra] Bring your vehicle expertise and vehicles you would like to debug to the BulletSim Vehicles Office Hour which is held every Tuesday at 0800 PST (8:00am PST, 1600 UTC) in the BulletSim region in OSGrid. -- ra Hopefully I have the networking issues resolved. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] IRegisterInterface for extending scene entities
Don't mean to be too much of a contrarian, but this has Bad Idea written all over it. I can see someone a year from now not finding that one wiki page which defines these conventions and just doing their own thing. Chaos ensues. My proposal attached object instances to the SOPs. This has two advantages over a simple key/value store: 1) the variables and types are defined -- anyone knows what is there and what type they should be. A key/value store will get into all the how do you store a float value issues (string? Float? Is the requestor wants a float and finds a string, should it be converted? Opps. Module A does the string to float conversion but Module B doesn't! Etc. Etc.) 2) there can be actions/methods on the attached instance -- functions like return the mesh representation of this object could be a call to the meshmerizer or a cache lookup or whatever. A key/value store would require all logic to be outside in another wrapper instance class that was associated with the SOP somehow. The problem with attaching instances is serialization/deserialization. Serialization could be the job of the instance (must implement ISerializable or maybe even ISerializableSOPParasite). Deserialization would require finding the class definition. All that C# reflection magic allows searching for the DLLs and if the defining DLL is not there, well, the code that would be using that function couldn't work anyway. Anyway, my vote is -1 for an arbitrary key/value store. Especially one that requires naming conventions and logic for understanding what's in that store scattered everywhere. -- ra -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Oren Hurvitz Sent: Thursday, January 03, 2013 9:48 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] IRegisterInterface for extending scene entities For namespacing we can take a pointer from MIME types: 1. Keys used by core OpenSim will have no prefix, e.g. media or prop.attr. 2. Keys created outside core OpenSim will use the vnd. prefix, followed by the name of the creating entity. For example: vnd.acme.myprop. We should stick to storing the data in a single field. Database access is much slower than in-memory string manipulation, so for any reasonable amount of data it would be faster to read and write it as part of the existing prims table rather than adding additional SQL operations on another table (primattr?). And of course, a separate table would be much more complicated to handle and I do like the simple life :) I did consider a different change: replacing OSD with JSON, which I like because of its simplicity and ubiquity. But I decided that it wouldn't make much of a difference; certainly not worth rewriting working code. Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/IRegisterInterface-for-extending-scene-entities-tp7578406p7578423.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ 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] IRegisterInterface for extending scene entities
I think adding a module allowing scripts to attach dynamic variables to SOPs is the right level of functionality. Just adding a key/value store is way too low a level. For instance, the JSONStore module (http://opensimulator.org/wiki/JsonStore_Module) creates a dynamic variable storage to share between scripts. Since it's made for sharing, a script can request events when values are updated. The module adds, as one piece, functionality for extension and communication between scripts. Does this attribute store enable such? Would a script want to know when one of the key/value pairs changed? Is polling suitable? Does the usage case just need static variable addition? As to the practical, implementation angle, yes, you are correct that adding an OSD store on a scene object is simpler. This is an open source project, after all, so this is just my opinion. -- ra -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Oren Hurvitz Sent: Friday, January 04, 2013 11:22 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] IRegisterInterface for extending scene entities The typing problem is already solved since the dynamic attributes are implemented using OSD. Your proposal is much more complicated than the currently proposed attributes, and I don't want to suppress a good solution in favor of a perfect solution that might never be implemented (I assume you're too busy with BulletSim to do this...) Furthermore, it would prevent a very exciting use-case: the ability to use dynamic attributes from a script, using OSSL. (Well, unless you add a module for that specific purpose, but in that case you just added a layer of indirection around the key-value store.) Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/IRegisterInterface-for-extending-scene-entities-tp7578406p7578425.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ 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] IRegisterInterface for extending scene entities
I agree with not reinventing the wheel. And your valid concerns about the implementation are probably just the tip of the iceberg. I have been toying with the architectural idea that OpenSim core only provides a basic framework. Functionalities are added as plugin modules rather than implemented as if's and tests imbedded in core. For instance, could linksets be implemented as a plugin module[1]? Or maybe entity physical representation (meshing)? I merely consider llSetKeyFrameMotion as a test case to expose needed core features which support plugin modules (Necessary events available? Correct data-structures exposed/hidden? ...) Like you, I am pretty sure the ability to programmatically extend scene entities will be needed and is a Good Thing. Since llSetKeyframeMotion has already been completed and will be incorporated soon, I'll look for another simple test case to exercise the requirements for full featured plugin modules. -- ra [1] Why would one want to do this? I've been thinking about fancy linksets where the joints are not fixed and static but could be parameterized and dynamic (hinges, sliders, 6DOF, ...). This could be used to support skeletons, doors with real hinges and/or weird and wonderful vehicles. Rather than mangling OpenSim core with lots of experimental code, it would be nice if I could build an ExtendedLinksets module that could be plugged in and experimented with. -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Melanie Sent: Friday, December 28, 2012 12:44 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] IRegisterInterface for extending scene entities Hi, first off, extending scene entities is a Good Thing. I'll think a bit about the ins and outs of it and the caveats (for instance, module load order will have some hidden traps for the unwary) and serialization - well, there be dragons, you can't serialize module refs/interfaces since the destination may not have them. llSetKeyfranedMotion can most likely not be implemented that way. We know, because we have implemented it. Also, there is no need to reinvent the wheel - llSetKeyframedMotion has been slated for core release for a while now, we just haven't found the dev time to extract it. So there is really no need for a second, competing implementation. So, in summary +1 on extension points for scene entities -0 on a second implementation of llSetKeyframedMotion as a tested and working one already exists. That's -0 because of you really want it I won't kee you from doing it - it's just a waste of effort. Melanie On 28/12/2012 08:38, Adams, Robert wrote: The discussion about the implementation of the llKeyframeMotion function hinted at a need for region modules to be able to add data and functions to existing scene items. Here is a modest proposal for discussion[1]. Define a general module/interface registration interface to add to EntityBase (and thus to SceneObjectGroup and ScenePresence). IRegisterInterface Void RegisterInterfaceT(T iface); Bool TryGetT(out T iface); T GetT(); Void ClearRegisteredInterfaces(); Any class that implements the IRegisterInterface interface would contain a: Private DictionaryType, object m_registeredInterfaces = new DictionaryType, object(); 'Scene' already has a RegisterModule interface which has a bunch of neat features (like being able to register multiple instances of the same interface type) but I'm not sure that is needed here (discussion?) Particularly industrious changing could merge this proposed interface and the existing 'Scene' functions. So, something like a llKeyframeMotion implementing region module could register a KeyframeMotionState type structure on the SOG to save information about the keyframe for that SOG. Other uses could be a uniform way for adding classes of functionality to scene objects (get me the interface for extracting the physical mesh for this SOG) or just adding limpet like code to a scene entity. Not sure of the nuances of serialization. I believe that the registered interfaces would just be serialized with the SOG (thus saving and restoring the values in the registered interface instances) but I can't be totally sure of that. Anyway, run your sword through this strawman. -- ra [1] This is similar to other interfaced proposed in the past (particularly one by Adam Frizby). ___ 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 ___ Opensim-dev mailing list Opensim-dev
Re: [Opensim-dev] IRegisterInterface for extending scene entities
Sounds perfect. The reason I started this here was to get the discussion bouncing. I'm interested in seeing past proposals. I searched around the OpenSimulator wiki looking for Adam's old proposal (Wiki's are just useless for finding and organizing things) but I could not find it. -- ra -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Melanie Sent: Friday, December 28, 2012 10:59 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] IRegisterInterface for extending scene entities I suggest we bounce this about a bit and maybe cooperatively work on a test case/POC. That will certainly clarify issues. I could also pull out the prosal I did for ReX which deals with this Melanie On 28 Dec 2012, at 18:38, Adams, Robert robert.ad...@intel.com wrote: I agree with not reinventing the wheel. And your valid concerns about the implementation are probably just the tip of the iceberg. I have been toying with the architectural idea that OpenSim core only provides a basic framework. Functionalities are added as plugin modules rather than implemented as if's and tests imbedded in core. For instance, could linksets be implemented as a plugin module[1]? Or maybe entity physical representation (meshing)? I merely consider llSetKeyFrameMotion as a test case to expose needed core features which support plugin modules (Necessary events available? Correct data-structures exposed/hidden? ...) Like you, I am pretty sure the ability to programmatically extend scene entities will be needed and is a Good Thing. Since llSetKeyframeMotion has already been completed and will be incorporated soon, I'll look for another simple test case to exercise the requirements for full featured plugin modules. -- ra [1] Why would one want to do this? I've been thinking about fancy linksets where the joints are not fixed and static but could be parameterized and dynamic (hinges, sliders, 6DOF, ...). This could be used to support skeletons, doors with real hinges and/or weird and wonderful vehicles. Rather than mangling OpenSim core with lots of experimental code, it would be nice if I could build an ExtendedLinksets module that could be plugged in and experimented with. -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Melanie Sent: Friday, December 28, 2012 12:44 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] IRegisterInterface for extending scene entities Hi, first off, extending scene entities is a Good Thing. I'll think a bit about the ins and outs of it and the caveats (for instance, module load order will have some hidden traps for the unwary) and serialization - well, there be dragons, you can't serialize module refs/interfaces since the destination may not have them. llSetKeyfranedMotion can most likely not be implemented that way. We know, because we have implemented it. Also, there is no need to reinvent the wheel - llSetKeyframedMotion has been slated for core release for a while now, we just haven't found the dev time to extract it. So there is really no need for a second, competing implementation. So, in summary +1 on extension points for scene entities -0 on a second implementation of llSetKeyframedMotion as a tested and working one already exists. That's -0 because of you really want it I won't kee you from doing it - it's just a waste of effort. Melanie On 28/12/2012 08:38, Adams, Robert wrote: The discussion about the implementation of the llKeyframeMotion function hinted at a need for region modules to be able to add data and functions to existing scene items. Here is a modest proposal for discussion[1]. Define a general module/interface registration interface to add to EntityBase (and thus to SceneObjectGroup and ScenePresence). IRegisterInterface Void RegisterInterfaceT(T iface); Bool TryGetT(out T iface); T GetT(); Void ClearRegisteredInterfaces(); Any class that implements the IRegisterInterface interface would contain a: Private DictionaryType, object m_registeredInterfaces = new DictionaryType, object(); 'Scene' already has a RegisterModule interface which has a bunch of neat features (like being able to register multiple instances of the same interface type) but I'm not sure that is needed here (discussion?) Particularly industrious changing could merge this proposed interface and the existing 'Scene' functions. So, something like a llKeyframeMotion implementing region module could register a KeyframeMotionState type structure on the SOG to save information about the keyframe for that SOG. Other uses could be a uniform way for adding classes of functionality to scene objects (get me the interface
[Opensim-dev] IRegisterInterface for extending scene entities
The discussion about the implementation of the llKeyframeMotion function hinted at a need for region modules to be able to add data and functions to existing scene items. Here is a modest proposal for discussion[1]. Define a general module/interface registration interface to add to EntityBase (and thus to SceneObjectGroup and ScenePresence). IRegisterInterface Void RegisterInterfaceT(T iface); Bool TryGetT(out T iface); T GetT(); Void ClearRegisteredInterfaces(); Any class that implements the IRegisterInterface interface would contain a: Private DictionaryType, object m_registeredInterfaces = new DictionaryType, object(); 'Scene' already has a RegisterModule interface which has a bunch of neat features (like being able to register multiple instances of the same interface type) but I'm not sure that is needed here (discussion?) Particularly industrious changing could merge this proposed interface and the existing 'Scene' functions. So, something like a llKeyframeMotion implementing region module could register a KeyframeMotionState type structure on the SOG to save information about the keyframe for that SOG. Other uses could be a uniform way for adding classes of functionality to scene objects (get me the interface for extracting the physical mesh for this SOG) or just adding limpet like code to a scene entity. Not sure of the nuances of serialization. I believe that the registered interfaces would just be serialized with the SOG (thus saving and restoring the values in the registered interface instances) but I can't be totally sure of that. Anyway, run your sword through this strawman. -- ra [1] This is similar to other interfaced proposed in the past (particularly one by Adam Frizby). ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] PRIM_PHYSICS_SHAPE_TYPE and PRIM_PHYSICS_SHAPE_CONVEX missing.
BulletSim uses convex hulls for all physical objects. It does not use the convex hull that may have been defined in the mesh but it generates an approximate convex hull using the HACD algorithm (http://codesuppository.blogspot.com/2011/05/hacd-hierarchical-approximate-convex.html). What do you require of the convex hulls? -- ra From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Dahlia Trimble Sent: Friday, December 21, 2012 5:16 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] PRIM_PHYSICS_SHAPE_TYPE and PRIM_PHYSICS_SHAPE_CONVEX missing. standard opensim with ODE physics does not support convex hull collision shapes. I believe BulletSim does but I don't know if it's been extended into the LSL API. On Fri, Dec 21, 2012 at 4:43 PM, R.Gunther ri...@rigutech.nlmailto:ri...@rigutech.nl wrote: i just wanted to try a default example of llSetKeyframedMotion script on http://wiki.secondlife.com/wiki/LlSetKeyframedMotion The Universal Hinged Motion in 8 Key Frames is useing llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_CONVEX]); It seems opensim dopnt support [PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_CONVEX] as setting ? Time to dig my own example script up ___ Opensim-dev mailing list Opensim-dev@lists.berlios.demailto: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
[Opensim-dev] BulletSim missive re ApplyImpulse and Buoyancy
For people playing with the BulletSim physics engine, the latest version in master fixes llSetBuoyancy() and fixes/improves llApplyImpulse(). That's the short report. Now for WAY more detail than anyone but a few physics tweekers care about: llSetBuoyancy now works for physical objects. The problem here was an oddity with how Bullet sets an object's gravity when the object is made physical. Today, buoyancy is implemented by changing the gravity effect on the individual object. Sometime in the future, buoyancy will be changed to apply an additional force to the physical object (like to push up and negate the effect of gravity). This will allow the setting of gravity for individual objects (a new SL feature that is not yet in OpenSim). llApplyImpulse now works close to how it does in SL. I spent some time pushing around blocks in OpenSim and SL in order to get movement about the same. Vehicle developers have mentioned that the implementation of llApplyImpulse has always been wonky and values from SL don't work in OpenSim. In digging into this, I've found some confusion in OpenSim's implementation of llApplyImpulse. llApplyImpulse is defined as a simple mass/force transfer. That is, llApplyImpulse(V * llGetMass(), false) will set the object moving at velocity V. The way forces are defined in physics engines is force per second. This means that for any individual simulation step (there are 11 per second in OpenSim), only part of the force is applied (forceAppliedThisStep = forcePerSecond * fractionOfSecondForThisSimulationStep). Since llApplyImpulse is an instantaneous push (it happens only once), to account for the reduction in the force based on the simulation step time, the impulse force can be multiplied internally in the physics engine driver to overcome this. It seems this correction has been implemented haphazardly in OpenSim. For instance, ODEPrim.AddForce multiplies the force by a constant 100[1]. SceneObjectGroup.GrabMovement divides the force by a constant 10[2] before calling PhysicalActor.AddForce. There are various other multiplications and divisions by 10 scattered about. I presume the 10 is because it is close to the number of simulation steps per second (11) and would give results that would seem correcter. The current resolution for BulletSim is to scale up the force specified to BSPrim.AddForce so the total force is applied the next simulation step. This makes llApplyImpulse work as it does in SL. A similar change was made to BSCharacter.AddForce. Hopefully, some weapons people will tell me if this is good or bad. Anyway, what users will notice is that llApplyImpulse is different with BulletSim and hopefully correct. -- ra [1] Why 100 I don't know as it is more than the 11 that would overcome the step time division. This could be for how ODE does sub-steps, but not sure. [2] I presume this was to overcome the 100 in ODE and to get a multiplier closer to the step divisor of 11. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OpenSim's direction after Linden cutting support, and the possibility of an official OpenSim viewer
The SL viewer model is an all in one application - viewer, editor, chat client, connection manager, ... Maybe a way of attacking the problem is to separate the parts and not think about building one behemoth application that does everything. Some projects (like Radegast or Lumiya) have made interesting progress on a viewer. Maybe content creation can be handled with Blender plugins? Maybe the chat/voice client could be one of the gaming services? Maybe the social connection/interaction framework could be Facebook (OK. No one would ever choose Facebook but any service is possible). Then, of course, there is the problem of the client/server protocol. LLLP (my term for Linden Lab Legacy Protocol) grew organically and had different problems to solve (remember the days when SL worked over dialup modems?). An organized, partition-able protocol would go a long way toward making new clients (mobile or continuously connected or ...) and servers (distributed or dynamically reconfigurable or ...) possible. It's just a new OpenSimulator region module to talk a new language. Anyway, just throwing that out there. -- ra From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Mircea Kitsune Sent: Tuesday, December 11, 2012 5:00 PM To: opensim-dev mailing list Subject: Re: [Opensim-dev] OpenSim's direction after Linden cutting support, and the possibility of an official OpenSim viewer Ironically, Firestorm is one of the viewers I like least. It's actually starting to worry me how it's monopolizing all third-party viewers and being the only v3 fork getting any attention at this day. Earlier I read that the admin of the Teapot viewer isn't updating Teapot any more because he's now working for Firestorm too... ugh _ I do appreciate their team's effort of course, but I don't like that it's becoming the only alternative, and I'm not sure what else to find and use that I'm comfortable with. But like I explained in the first email, I believe the SL code base is the only path we've got rather than a dead end. SL's system (which OpenSim primarily went with during those years) is a very complex thing. Implementing all of its features from scratch in a good and consistent way would be an effort so big there will likely never be anyone doing it when SL is already there. There was an original viewer once which could render avatars, terrain and objects, but that was about it. The list of features and details is too big. The building tools with grid snapping, arrows to drag / rotate objects, texture position editing, etc. The avatar customization menu, where you customize worn shapes / skins / alpha masks / clothing. Avatar physics, such as clothing fluttering in the wind. The terrain editor with the raise / lower / flatten / smooth tools. The IM / chat / groups systems with all their sub-features. Voice chat support. Sculpt primitives and mesh rendering. Ability to play media on a prim and use HTML pages on object surfaces. The windlight sky and environment (which can also be set as a parcel property). Particles, sounds, spinning objects (llTargetOmega) and the many things you do with LSL scripts. Post-processing with bloom, depth of field, bump-mapping, etc. All this and more would take beyond a decade to re-create from scratch, and I couldn't imagine a new viewer ever doing them all as well as Second Life. If anyone would ever get that done from zero as part of a FOSS viewer, I will consider them a scientist that deserves a job at NASA :) I'm actually surprised even LL did so much in just 8 years, but what was achieved is really impressive. Overall I just don't think it's a possible goal, and at the same time I don't believe OpenSim can expect other dev teams to maintain them a SL viewer (just what I think). With Firestorm taking up everything, I'm already having a hard time finding a viewer good for me to use, and I'd like to know what can be expected in the recent future. Date: Tue, 11 Dec 2012 13:20:15 -0800 From: javajo...@gmail.commailto:javajo...@gmail.com To: ri...@rigutech.nlmailto:ri...@rigutech.nl; opensim-dev@lists.berlios.demailto:opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] OpenSim's direction after Linden cutting support, and the possibility of an official OpenSim viewer Hmm, it's been Over Two Years since I wrote this on my old blog: http://www.daniel.org/blog/2010/09/19/in-unity-a-way-forward/ I wonder what the state of the art is for any viewers based on Unity, WebGL, or something else? The LL code base is an evolutionary dead end. Firestorm does a great job of making the best of it, and it deserves to be the #1 viewer. Ongoing Kudos to the FS team! Having said that, no TPV (or LL) viewer is going to catch up to what is possible on a better foundation. It would be great to see two things happen: 1) TPV effort consolidate *even more* around Firestorm.. make it
[Opensim-dev] BulletSim vehicles office hours
Much of BulletSim[1] development is being focused on vehicles with the goal of happy implementations for all of the virtual world vehicle types. For hands-on communication between the BulletSim developers and vehicle creators, there will be BulletSim Vehicles Office Hour held in the OSGrid region BulletSim [2]. The office hour time is initially set tobe Tuesdays at 0800 PST (1600 UTC) [3]. Bring your vehicle expertise and vehicles you would like to debug! -- ra [1] The new OpenSimulator physics engine based on Bullet (http://bulletphysics.org/) . [2] The OSGrid regions BulletSim, BulletSim01, BulletSim10 and BulletSim11 are regions running the latest and greatest version of BulletSim and are there for vehicle and other physics testing. When you find things that need changing, file a Mantis, IM Robert Adams in OSGrid or find me as radams1 on the opensim-dev IRC channel. [3] If there is a better time for the majority of vehicle developers, email me and we can discuss movement to a more convenient time. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] PhysicalPrimMax numbers for BulletSim
There has been an ongoing discussion on physical prim maximum size. Lani Global did some testing and published a graph of her results at http://opensimulator.org/wiki/User:LaniGlobal#PhysicalPrimMax_Size_Testing . Her testing showed that, for ODE, a max size of 32m resulted in a livable frame rate degradation. I performed the same tests with BulletSim and discovered that a single sphere (native physical shape) or a single torus (mesh/hull shape) did not reduce simulator frame rate no matter the size of the object. So, I created a single, standalone region with lumpy terrain and dropped different quantities of large shapes. The resulting frame rates were: NumberNumber SPHERE1 4 8 16 32TORUS[2] 1 4 8 32 64 + + 10 | 55 55 55 55 55 10 | 55 55 55 55 55 S 20 | 55 55 55 55 55 S 20 | 55 55 55 26 13 i 32 | 55 55 55 55 55 i 32 | 55 55 40 16 z 64 | 55 55 55 49 49 z 64 | 55 50 20 e 100| 55 54 49 47 [1]e 100| 40 15 [1] My setup wasn't large enough to hold 32 100m spheres. [2] The torus height is about one third of the width because I preferred the doughnut shape. A few pictures of the experiments (one region with walls): https://dl.dropbox.com/u/86260377/20121107_009.png https://dl.dropbox.com/u/86260377/20121107_012.png https://dl.dropbox.com/u/86260377/20121107_017.png https://dl.dropbox.com/u/86260377/20121107_019.png https://dl.dropbox.com/u/86260377/20121107_022.png https://dl.dropbox.com/u/86260377/20121107_026.png It looks like, for BulletSim, a physical object max size of 32m is acceptable and 64m would probably be OK. The physics frame rate is a function of the number and size of large, physical prims. The above numbers are for multiple of the same object. The next tests should be on large sized linksets (for instance, two 5m cubes that are 32m apart and linked and physical). -- ra ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] BulletSim testing
I have been working on a Bullet based physics engine for OpenSimulator. It is in a fairly stable state and works pretty well as a regular physics engine. If you have the time and resources, I invite testing and stressing. The version checked into 'master' sources works on Windows and Linux both 32 and 64 bit. BulletSim is turned on my changing the physics engine selection in OpenSim.ini - change physics=OpenDynamicsEngine to physics=BulletSim. That's it! Brakages should go into Mantis (Category: [REGION] Physics Engine, Physics Engine: BulletSim). I especially want vehicles to work - any input on what needs fixing or tuning would be great. Thanks. -- ra ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Whats best way to get more debug info on linux mono.
I'm very interested in getting some test vehicles. Is there a repository or sample physical vehicles I can fetch? -- ra P.S.: I emailed the gmail address from the header but received no reply. -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Brianna Sent: Tuesday, October 02, 2012 10:59 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Whats best way to get more debug info on linux mono. Decided to run a train test .. Icy-Bridge 16gb running around a region edge.. on 0.7.5 dev / Suse 12.2 beta 64 CPU load averages: 0.00 (1 mins) , 0.01 (5 mins) , 0.05 (15 mins) as seen, is a near no load CPU wise. if you'd like a few Vehicles -- sailboats, cars or waypoint items (train) for Bullet... do chase me or Kitto. Bri Hasp -Original Message- From: Adams, Robert Sent: Tuesday, October 02, 2012 8:36 AM To: ri...@rigutech.nl ; opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Whats best way to get more debug info on linux mono. I'm working on the new Bullet based physics engine for OpenSim. I want to make it work for vehicles and a good stress test is something I could use. Could you send me an email and we can see if there is some way to set up a test environment. Thanks. -- ra -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of R.Gunther Sent: Monday, October 01, 2012 3:57 PM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] Whats best way to get more debug info on linux mono. Well i switched back to linux. But my train is crashing the sim regulair sofar in 24 hours with stacktrace. My train is a good stresstest. grin. Maby i can get more intressting data for the devs. Only need to keep a bit simple to get the data. Useing opensuse. ___ 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 ___ 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] Whats best way to get more debug info on linux mono.
I'm working on the new Bullet based physics engine for OpenSim. I want to make it work for vehicles and a good stress test is something I could use. Could you send me an email and we can see if there is some way to set up a test environment. Thanks. -- ra -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of R.Gunther Sent: Monday, October 01, 2012 3:57 PM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] Whats best way to get more debug info on linux mono. Well i switched back to linux. But my train is crashing the sim regulair sofar in 24 hours with stacktrace. My train is a good stresstest. grin. Maby i can get more intressting data for the devs. Only need to keep a bit simple to get the data. Useing opensuse. ___ 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] Multi-region OAR format
I’m not sure I see the advantage of multiple regions in one oar file. Say I have a 3x3 set of regions saved in a backup oar file. I might want to restore one. That necessitates new command line parameters for selection, etc. To handle multiple regions, another approach is to push the grouping up a level and add commands for loading and creating multiple oar files with one command. That keeps the existing oar file format but solve the grouping feature. Or how about if the target of a ‘load oar’ is a directory, it loads all of the oar files therein? -- ra From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Oren Hurvitz Sent: Friday, July 20, 2012 6:39 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Multi-region OAR format On Fri, Jul 20, 2012 at 4:15 PM, Robert L martin [via opensim-dev] [hidden email]/user/SendEmail.jtp?type=nodenode=7578166i=0 wrote: okay so if i wanted to make an OAR for Bad Wolf Island with a total of nine regions it would have row 1 (south) Southwest, South center , South East row 2 (center) West Center, Center, East Center row 3 (north) NorthWest , North Center, North east and if i wanted to have a 2X4 region then it would be row 1 (south) South West , South Center West, South Center East , South East row 2 (north) North West, North Center West, North Center East, North East and any region without data will create a hole in the sim That's right. if the server can be made to handle it i would suggest that a dummy manifest be used to create blank regions (modes would be fixed height, Blend or random) If I understand you correctly, you're asking for the load-oar command to create regions where none existed before. It doesn't do that currently, and I don't intend to make it start doing so. There are other ways to create regions (see Regions.ini), and I don't intend to add to them as that's a different feature. View this message in context: Re: Multi-region OAR formathttp://opensim-dev.2196679.n2.nabble.com/Multi-region-OAR-format-tp7578162p7578166.html Sent from the opensim-dev mailing list archivehttp://opensim-dev.2196679.n2.nabble.com/ at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Question/Suggestion regarding *.ini files
If you want to create your own organization of ini files, OpenSimulator provides several mechanisms: OpenSimDefaults.ini is always read on startup OpenSim.ini is read after Ini files that exist in the bin/config/ directory are read There is an include mechanism (checkout out then architecture section of the stock OpenSim.ini for examples) XML formatted configuration files can be read from an URL (using the include mechanism) The possibilities are endless. The downside to building your own ini files is that, as OpenSimulator adds and modifies new parameters, your configuration files become stale and it gets harder and harder to verify that your configuration is reasonable for the current OpenSimulator sources. -- ra From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Markus Metzmacher Sent: Tuesday, October 04, 2011 11:41 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Question/Suggestion regarding *.ini files I do not speak about a paradigm change (OpenSim as is, is super and the progress you developer are showing, is tremendous) - i only speak about the possibility, to extract specific configuration sections into separate files. Maybe it is possible (you mentioned, that it can be done by the admin?!). Thats's all, what needed. Maybe only a hint to the explanation of this possibility and a how to is enough? As I said - maybe I missed something? But, of course, I only speak for me and myself and that's only my outcome of my experience. Markus [cid:image001.jpg@01CC8296.1DC448D0] Melaniemailto:mela...@t-data.com 4. Oktober 2011 19:58 The way the system is working now means the user can merge a working configuration and then edit only a subset. There is no need for a paradigm change because the goal is already achievable. It doesn't do this out of the box but can easily be made to do it by the admin of the system. Grids are too different from each other to accommodate their hypothetical needs in the base distro. Melanie ___ Opensim-dev mailing list Opensim-dev@lists.berlios.demailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev [cid:image001.jpg@01CC8296.1DC448D0] Markus Metzmachermailto:i...@secondlearning.de 4. Oktober 2011 18:24 Dear All, I've a question regarding the OpenSim.ini, *Common.ini, etc. These ini files are heavily influenced by the implementations and developments you make. Some parameters never change (i.e. Database settings, Group settings etc.) but others do. Is it possible, to inject the code, which is more static by including files? Example: the port, which is used for a region/simulation is configured in the [Network] section and never changes because, once it is running on this port, you will never change it - especially if you host regions on one server. I think, it might be a good idea to call a separate (static) file like 'include network_section path/network.ini' to inject the code like you do to distinguish between HyperGrid, Standalone, etc. The user (Grid Admin or, if on another server and allowed by the Grid Admin, the region admin) then has only to enable/disable the features in the (new) OpenSim.ini without taking care about the settings, which depends on that specific region like database, port , groups, etc ... In fact, this will reduce upgrade times needed for upgrading a full grid from day's to hours. Especially most tasks can be automated. Maybe this option is available today (i don't know) but if not, it might be a good idea to implement it? If I missed something, perhaps only a hint of this possibility is missing on opensimulator.org? Also, I think, the possibilities of the switches within ROBUST.ini are not that good described. I do not know, if robust.ini is the file, which plays the only role for the asset/inventory/user. server environment. Does OpenSim.ini plays a role for robust server only as well? I think, others are puzzling exactly the same. What do you think? Sorry - if there's a better place, to place my questions, please tell me. With kind Regards Markus ___ Opensim-dev mailing list Opensim-dev@lists.berlios.demailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev inline: image001.jpg___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] BulletSim in master
To accompany the other attempts at porting the Bullet physics engine into
OpenSimulator, BulletSim has been merged into the master OpenSimulator branch.
It is nowhere near ready to replace ODE but it has basic physical object
functionality, good performance and no crashes. Some of the current features:
The latest version of Bullet (2.78)
Use of Bullet native shapes for cubes and spheres (with any
scaling)
Triangle meshes for static objects and automatically generated
convex hulls for physical objects
Collision events for objects and terrain
Initial code for linksets (but debugging is needed)
Initial code for vehicles (but vehicles don't work yet)
Gettable and settable parameters ('physics' console command)
Efficient interface between the C# and C++ code
BulletSim is enabled by setting physics = BulletSim in OpenSim.ini. There are
dll's for 32 and 64 bit Windows and so's for 32 and 64 bit Linux. (For 64 bit
Windows, you need to copy BulletSim-x86_64.dll onto BulletSim.dll).
BulletSim consists of two parts: the C# module (which interfaces between
OpenSimulator and the C++ code) and C++ code (which makes the calls to a
statically linked Bullet physics engine). The C++ code is in the 'opensim-libs'
repository
(http://opensimulator.org/svn/opensim-libs/trunk/unmanaged/BulletSim/;) and
the C# code is now in the OpenSimulator git 'master' branch
(OpenSim/Region/Physics/BulletSPlugin/).
There is a lot of tuning and adaptation that needs to happen yet and anyone who
wants to help feel free to jump in. I (radams1) am often on the IRC channels so
let's talk.
-- ra
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Plugins
A longer answer is yes, but... C# is a managed runtime environment so there are some hoops to jump through to add and interface to native/unmanaged C and C++ code. You create a C# OpenSimulator module which uses P/Invoke or equivalent to marshal and connect to your unmanaged C/C++ code. While doable (and I've done it a few times and it's not all that hard), the major problem is that the OpenSimulator build environment builds C# so you have a separate build environment for your C/C++ code and you end up distributing binary .dll's and .so's. Thus the short answer. Unless you have some strange interfacing requirements or some extreme performance requirements, C# is very performant and it is OpenSimulator's native environment. -- ra -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey Sent: Wednesday, August 10, 2011 7:34 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Plugins On 10/08/11 23:34, Tyler McMaster wrote: Is it possible to make a plugin for OpenSim in C or is it only C#? Short answer, stick to C#. Doing C would be complex and very suboptimal. -- Justin Clark-Casey (justincc) http://justincc.org/blog http://twitter.com/justincc ___ 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] Built libbullet shared object libraries for Linux but this isn't what you wanted!
I got the same errors when I tried your Makefile -- it is odd that the MS compiler didn't catch some of these. A few simple changes, though, allows it to compile. I will have Dan check in the changes. I didn't have time to link and run it yesterday but I will give it a try today. -- ra -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey Sent: Wednesday, June 29, 2011 4:51 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Built libbullet shared object libraries for Linux but this isn't what you wanted! On 27/06/11 16:52, Adams, Robert wrote: Building Bullet itself is a start. Thanks Justin. The makefile should be fairly straight forward as there are just the two cpp files and one .h file with the only dependencies being on the std library and Bullet itself. As you now know, Bullet used CMAKE for its build/configuration tool and I don't know if there is a way to link a BulletSim build into it (put the Bullet directory under BulletSim and do a CMAKE which builds both together). I'm setting up a Linux build environment so I should be able to help anyone working on this by next weekend. I'm doing some stress testing this week and then I will look into linksets again -- I want to get vehicles working. I put in a scratch Makefile and fixed one definition issue in BulletSim.cpp. However, on make this still brings up the errors BulletSim.cpp:38:14: error: 'gDeactivationTime' was declared 'extern' and later 'static' BulletDynamics/Dynamics/btRigidBody.h:29:17: error: previous declaration of 'gDeactivationTime' BulletSim.cpp: In member function 'int BulletSim::PhysicsStep(btScalar, int, btScalar, int*, EntityProperties***, int*, unsigned int**)': BulletSim.cpp:107:79: error: cast from 'void*' to 'unsigned int' loses precision BulletSim.cpp:108:79: error: cast from 'void*' to 'unsigned int' loses precision BulletSim.cpp: In member function 'btCollisionShape* BulletSim::CreateShape(ShapeData*)': BulletSim.cpp:405:61: error: no matching function for call to 'BulletSim::AdjustScaleForCollisionMargin(btCollisionShape*, btVector3)' BulletSim.h:469:7: note: candidate is: void BulletSim::AdjustScaleForCollisionMargin(btCollisionShape*, btVector3) BulletSim.cpp:426:62: error: no matching function for call to 'BulletSim::AdjustScaleForCollisionMargin(btCollisionShape*, btVector3)' BulletSim.h:469:7: note: candidate is: void BulletSim::AdjustScaleForCollisionMargin(btCollisionShape*, btVector3) BulletSim.cpp:432:61: error: no matching function for call to 'BulletSim::AdjustScaleForCollisionMargin(btCollisionShape*, btVector3)' BulletSim.h:469:7: note: candidate is: void BulletSim::AdjustScaleForCollisionMargin(btCollisionShape*, btVector3) BulletSim.cpp: In member function 'SweepHit BulletSim::ConvexSweepTest(unsigned int, btVector3, btVector3, btScalar)': BulletSim.cpp:1166:95: error: cast from 'void*' to 'unsigned int' loses precision BulletSim.cpp: In member function 'RaycastHit BulletSim::RayTest(unsigned int, btVector3, btVector3)': BulletSim.cpp:1209:70: error: cast from 'void*' to 'unsigned int' loses precision make: *** [BulletSim.o] Error 1 It's a long time since I did any significant c/cpp (and then it wasn't on Linux) so I'm not sure why this is happening. Maybe it's gcc specific. I was able to pull opensim-libs anonymously last week (http://opensimulator.org/svn/opensim-libs). Has it broken since then? Thanks Robert - I was trying the wrong url. I put the information into the wiki. -- ra -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey Sent: Sunday, June 26, 2011 4:48 PM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] Built libbullet shared object libraries for Linux but this isn't what you wanted! Hi Robert. I briefly putzed around with building shared object Bullet 2.78 under Linux tonight and popped the results in as commit 23bf773 on the bulletsim branch. However, I just realised that you weren't asking for the bullet libraries to be built. What you were really asking for in http://lists.berlios.de/pipermail/opensim-dev/2011-June/010271.html were Linux/OSX makefiles to build your BulletSim.dll interfacing library in the opensim-libs svn repo (for which anonymous access is unfortunately not currently working - this need to be fixed). That doesn't look too difficult but it's a little more involved for me since it's a long time since I wrote a Makefile. I don't know when I might get a slice of time to do that, so I think help from anybody else would still be very much appreciated. -- Justin Clark-Casey (justincc) http://justincc.org/blog http://twitter.com/justincc ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman
Re: [Opensim-dev] Built libbullet shared object libraries for Linux but this isn't what you wanted!
Building Bullet itself is a start. Thanks Justin. The makefile should be fairly straight forward as there are just the two cpp files and one .h file with the only dependencies being on the std library and Bullet itself. As you now know, Bullet used CMAKE for its build/configuration tool and I don't know if there is a way to link a BulletSim build into it (put the Bullet directory under BulletSim and do a CMAKE which builds both together). I'm setting up a Linux build environment so I should be able to help anyone working on this by next weekend. I'm doing some stress testing this week and then I will look into linksets again -- I want to get vehicles working. I was able to pull opensim-libs anonymously last week (http://opensimulator.org/svn/opensim-libs). Has it broken since then? -- ra -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey Sent: Sunday, June 26, 2011 4:48 PM To: opensim-dev@lists.berlios.de Subject: [Opensim-dev] Built libbullet shared object libraries for Linux but this isn't what you wanted! Hi Robert. I briefly putzed around with building shared object Bullet 2.78 under Linux tonight and popped the results in as commit 23bf773 on the bulletsim branch. However, I just realised that you weren't asking for the bullet libraries to be built. What you were really asking for in http://lists.berlios.de/pipermail/opensim-dev/2011-June/010271.html were Linux/OSX makefiles to build your BulletSim.dll interfacing library in the opensim-libs svn repo (for which anonymous access is unfortunately not currently working - this need to be fixed). That doesn't look too difficult but it's a little more involved for me since it's a long time since I wrote a Makefile. I don't know when I might get a slice of time to do that, so I think help from anybody else would still be very much appreciated. -- Justin Clark-Casey (justincc) http://justincc.org/blog http://twitter.com/justincc ___ 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
[Opensim-dev] BulletSim added to OpenSimulator repository
A new branch ('bulletsim') has been added to the OpenSimulator repository. The
branch contains BulletSim - a port of the latest Bullet physics engine for
OpenSimulator. Initial tests show that the Bullet physics engine simulates
more physical objects and supports more avatars than ODE. For instance, 1900
balls in a Galton box as opposed to 800 balls with ODE (running at simulator 30
FPS).
BulletSim currently provides the basic functionality necessary for most
simulations (avatar walking and flying, interaction of physical prims and
collision events). We would like to bring BulletSim up to the level where it is
at least functionally equivalent to ODE.
BulletSim consists of two parts: BulletSPlugin which is the C# module that
interfaces to OpenSimulator (set 'physics = BulletSim' in the ini file). The
other part is BulletSim.dll which is C++ code for the low level interface to
the Bullet physics engine. The C++ code has been built and tested with Visual
Studio for both 32 and 64 bit systems. What is desperately missing is the build
scripts to compile and link this BulletSim module on Linux/Mono systems.
While BulletSim has the basic functionality, there are many things to be
finished. As mentioned above, the most important is building and testing on
Linux/Mono. Other items:
-- Fix folding up feet
-- Complete coding and debugging of linksets (partially implemented)
-- Improve marshaling (could be made much more efficient with pinned memory
blocks)
-- Scale avatar capsule as avatar size is changed
There is a more complete list at the beginning of BSScene.cs.
I (radams1) am usually on #opensim-dev during the day (PDT). I am continuing
development of BulletSim but, if anyone wants to help, feel free to jump in.
-- Robert Adams, Intel Labs
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
