Re: [Opensim-dev] Collada as Model Format
A physics engine that internally handles COLLADA data directly? Possible, but surely not practical for performance. This is why the COLLADA standard defines refineries to convert and optimize formats. The COLLADA tool chain needs to compile DAE files like gcc compiles C/C++ files. The physics engine should be able to handle the compiled output as if no COLLADA support was added in the build options. It's not the first time I seen people look directly at the XML schema and try to support that directly, like they somehow missed the refinery process or thought it wasn't needed. A real-time COLLADA refinery built into the engine... maybe sometime in the future with extra cores to spare. Still, it doesn't make sense since the DAE file has much more than physical data. COLLADA used to exchange assets... +1 COLLADA used as built-in to a real-time render engine... -1 Frisby, Adam wrote: And to attach a demo object, the size shoots up to 1GB. Some things XML can't solve, 3D model storage is one of them. ;) Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Teravus Ovares Sent: Sunday, 17 May 2009 1:25 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Collada as Model Format The only thing that is frustrating about COLLADA.. is it's hard to support fully.For example..Bullet is a Physics engine that totals ~250kb.BUT if you build in COLLADA support, it becomes 6MB. :P On 5/16/09, Gustavo Alberto Navarro Bilbao wrote: A silly question: �Can be compatible OGRE and COLLADA at the same time?. I say that because I suppose that there is a great time and effort spent by the realxtend and SIRIKATA' teams, working on, and many are expecting in July for the new RX-NG and SIRIKATA, and would be a pity not to make the already developed. Best regards 2009/5/16 Jani Pirkola Immersive Education initiative (IEd) has decided in its Technical Working Group to support COLLADA as the format to transfer assets between different platforms. http://maxping.org/business/news/immersive-education-adds-support- for-realxtend.aspx To further support COLLADA, IEd and Khronos launched a contest for developing content using the format. http://maxping.org/business/real-life/champion-the-3d-web-using- collada.aspx Best regards, Jani 2009/5/16 Tommi Laukkanen Hello As custom viewers start to emerge I would like to point to Collada specification as one format which could be used to support freestyle models (meshes): This document describes the COLLADA schema. COLLADA is a COLLAborative Design Activity that defines an XML-based schema to enable 3-D authoring applications to freely exchange digital assets without loss of information, enabling multiple software packages to be combined into extremely powerful tool chains. The specification: http://www.khronos.org/files/collada_spec_1_4.pdf The schema: http://www.khronos.org/files/collada_schema_1_4 -tommi ___ 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 ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] WARNING: r9562 may break things
Trunk is the developer's working copy, and is guaranteed to veryt likely be broken in one manner or another at any given time. Sometimes a revision is tagged as a release, those are usually tested and will often contain less bugs than any random version in svn. On Sun, May 17, 2009 at 10:03 PM, wrote: > I really hope you guys don't do all your work in trunk, not sure what you > policy is but to me only tested code should be in truck which means no one > should be working directly in trunk for anything. > > Also something I wanted to share. I have been sitting in the OpenSim IRC > channel for weeks and looking for some opportunities to help but for me at > least, can't speak for everyone, it is really hard to know what efforts are > going. Is there some kind of release plan or documented branch plan? I > have heard people say they don't like to document and plan but I do think no > documentation or planning makes it hard for others to help. At least for > me. > > Kevin Tweedy > > > > > > Original Message > Subject: Re: [Opensim-dev] WARNING: r9562 may break things > From: d...@metaverseink.com > Date: Fri, May 15, 2009 9:26 am > To: opensim-dev@lists.berlios.de > > I had no idea there was a separate branch about this! > We should definitely work together on this, rather than separate. > Talking about lack of communication... :D > > > MW wrote: > > The main concern I have is that the whole empty shell for servers and > > then loading services sounds exactly like myself and mikkopa having been > > doing in the GenericGridServerConcept branch. The way it works is that > > there is a single base server that loads plugins, the plugins can be any > > service. At the moment the plugins/services are the logic from the > > current user server and grid server. As we were taking it one step at a > > time and just getting the base architecture. So with the base server you > > could have it so it could load all the plugins and act as a combined > > user server and grid server (and any other services in the future) or > > have separate servers for each as we have now. It also uses ini (nini) > > to config the servers and plugins. But of course the work isn't > > finished, but everyone could have worked on it and improved it. > > > > The reason this was done in a branch is because its big changes and I > > wanted to get it into some working condition before it went into trunk. > > Also the fact that it hadn't been talked about in enough details to get > > a agreement on if it should go into trunk. > > > > Now I'm not saying that work in what we should have in trunk. I'm just > > saying there is that work going on, and anyone can get involved in it.. > > And we should be working together to make it into what we want. But > > instead we have the situation where we have this new idea what sounds a > > lot like what has been done in the branch but rather all of us work > > together we have ended up we two concurrent work in progresses. > > > > I'm completely fine with going with a different architecture to the one > > in the branch, although it does sound very similar to melanie's idea > > anyway. But really we should talk about what is wrong with the current > > work that is going on in that branch. Not just ignore it and start on > > her own idea without proper input. We are a team and we have to work as > > a team. > > > > So my problem isn't with the architecture, far from it from what has > > been described, just the problem is the way its been done. Not enough > > details of the plan had been published and just ignoring other current > > work, what just doesn't help with the future of the project if everyone > > just goes off and does there own thing, even if thats duplication other > > current work. > > > > Anyway I think if nothing else this just goes to show there is no point > > in us doing anything in branches ever again. > > > > --- On *Fri, 15/5/09, d...@metaverseink.com //* > > wrote: > > > > > > From: d...@metaverseink.com > > Subject: Re: [Opensim-dev] WARNING: r9562 may break things > > To: opensim-dev@lists.berlios.de > > Date: Friday, 15 May, 2009, 4:55 PM > > > > Let me explain in my own words what this new architecture is all about. > > > > My original intention with this was purely to improve the software > > architecture, so that we and others can do a lot more variation very > > easily. (This was not just my intention, we all know that what we have > > right now is a pain in the neck, and that it has always been a goal to > > improve it) > > Melanie thinks that since we're at it, we might as well improve the > > protocols on the wire and move everything to HTTP/REST. While I agree > > that's where we should end up, I would do the transition in 2 steps: > > first step would be to put the new software architecture in place, the > > second would be to improve the protocols on the wire. And I would keep > > the old service connectors around. But I have no problems with changing >
Re: [Opensim-dev] WARNING: r9562 may break things
I really hope you guys don't do all your work in trunk, not sure what you policy is but to me only tested code should be in truck which means no one should be working directly in trunk for anything. Also something I wanted to share. I have been sitting in the OpenSim IRC channel for weeks and looking for some opportunities to help but for me at least, can't speak for everyone, it is really hard to know what efforts are going. Is there some kind of release plan or documented branch plan? I have heard people say they don't like to document and plan but I do think no documentation or planning makes it hard for others to help. At least for me. Kevin Tweedy Original Message Subject: Re: [Opensim-dev] WARNING: r9562 may break thingsFrom: d...@metaverseink.comDate: Fri, May 15, 2009 9:26 amTo: opensim-dev@lists.berlios.deI had no idea there was a separate branch about this!We should definitely work together on this, rather than separate.Talking about lack of communication... :DMW wrote:> The main concern I have is that the whole empty shell for servers and > then loading services sounds exactly like myself and mikkopa having been > doing in the GenericGridServerConcept branch. The way it works is that > there is a single base server that loads plugins, the plugins can be any > service. At the moment the plugins/services are the logic from the > current user server and grid server. As we were taking it one step at a > time and just getting the base architecture. So with the base server you > could have it so it could load all the plugins and act as a combined > user server and grid server (and any other services in the future) or > have separate servers for each as we have now. It also uses ini (nini) > to config the servers and plugins. But of course the work isn't > finished, but everyone could have worked on it and improved it.> > The reason this was done in a branch is because its big changes and I > wanted to get it into some working condition before it went into trunk. > Also the fact that it hadn't been talked about in enough details to get > a agreement on if it should go into trunk.> > Now I'm not saying that work in what we should have in trunk. I'm just > saying there is that work going on, and anyone can get involved in it.. > And we should be working together to make it into what we want. But > instead we have the situation where we have this new idea what sounds a > lot like what has been done in the branch but rather all of us work > together we have ended up we two concurrent work in progresses.> > I'm completely fine with going with a different architecture to the one > in the branch, although it does sound very similar to melanie's idea > anyway. But really we should talk about what is wrong with the current > work that is going on in that branch. Not just ignore it and start on > her own idea without proper input. We are a team and we have to work as > a team.> > So my problem isn't with the architecture, far from it from what has > been described, just the problem is the way its been done. Not enough > details of the plan had been published and just ignoring other current > work, what just doesn't help with the future of the project if everyone > just goes off and does there own thing, even if thats duplication other > current work.> > Anyway I think if nothing else this just goes to show there is no point > in us doing anything in branches ever again.> > --- On *Fri, 15/5/09, d...@metaverseink.com //* > wrote:> > > From: d...@metaverseink.com > Subject: Re: [Opensim-dev] WARNING: r9562 may break things> To: opensim-dev@lists.berlios.de> Date: Friday, 15 May, 2009, 4:55 PM> > Let me explain in my own words what this new architecture is all about.> > My original intention with this was purely to improve the software> architecture, so that we and others can do a lot more variation very> easily. (This was not just my intention, we all know that what we have> right now is a pain in the neck, and that it has always been a goal to> improve it)> Melanie thinks that since we're at it, we might as well improve the> protocols on the wire and move everything to HTTP/REST. While I agree> that's where we should end up, I would do the transition in 2 steps:> first step would be to put the new software architecture in place, the> second would be to improve the protocols on the wire. And I would keep> the old service connectors around. But I have no problems with changing> both things at the same time and getting rid of the old service> connectors... Anyway, let me explain.> > The new architecture that Melanie is putting in place is wonderful! The> focus is now radically on *services*, servers being shells that load> any> combination of those services. Conceptually, a Service is tuple> > > ServiceImplementation,> ServiceConnectorOut,> ServiceConnectorIn>> > Callers of a service know only of IService; that IService on the client> side is mapped to a ServiceConnectorOut at ini
Re: [Opensim-dev] Collada as Model Format
And to attach a demo object, the size shoots up to 1GB. Some things XML can't solve, 3D model storage is one of them. ;) Adam > -Original Message- > From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- > boun...@lists.berlios.de] On Behalf Of Teravus Ovares > Sent: Sunday, 17 May 2009 1:25 PM > To: opensim-dev@lists.berlios.de > Subject: Re: [Opensim-dev] Collada as Model Format > > The only thing that is frustrating about COLLADA.. is it's hard to > support fully.For example..Bullet is a Physics engine that > totals ~250kb.BUT if you build in COLLADA support, it becomes 6MB. > :P > > On 5/16/09, Gustavo Alberto Navarro Bilbao > wrote: > > A silly question: ¿Can be compatible OGRE and COLLADA at the same > time?. I > > say that because I suppose that there is a great time and effort > spent by > > the realxtend and SIRIKATA' teams, working on, and many are > expecting in > > July for the new RX-NG and SIRIKATA, and > > would be a pity not to make the already developed. > > > > Best regards > > > > > > > > 2009/5/16 Jani Pirkola > > > >> Immersive Education initiative (IEd) has decided in its Technical > Working > >> Group to support COLLADA as the format to transfer assets between > >> different > >> platforms. > >> > >> http://maxping.org/business/news/immersive-education-adds-support- > for-realxtend.aspx > >> > >> To further support COLLADA, IEd and Khronos launched a contest for > >> developing content using the format. > >> > >> http://maxping.org/business/real-life/champion-the-3d-web-using- > collada.aspx > >> > >> Best regards, > >> Jani > >> > >> 2009/5/16 Tommi Laukkanen > >> > >> Hello > >>> > >>> As custom viewers start to emerge I would like to point to Collada > >>> specification as one format which could > >>> be used to support freestyle models (meshes): > >>> > >>> This document describes the COLLADA schema. COLLADA is a > COLLAborative > >>> Design Activity that > >>> defines an XML-based schema to enable 3-D authoring applications to > >>> freely exchange digital assets > >>> without loss of information, enabling multiple software packages to > be > >>> combined into extremely powerful > >>> tool chains. > >>> > >>> The specification: > >>> > >>> http://www.khronos.org/files/collada_spec_1_4.pdf > >>> > >>> The schema: > >>> > >>> http://www.khronos.org/files/collada_schema_1_4 > >>> > >>> -tommi > >>> ___ > >>> 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] Collada as Model Format
The only thing that is frustrating about COLLADA.. is it's hard to support fully.For example..Bullet is a Physics engine that totals ~250kb.BUT if you build in COLLADA support, it becomes 6MB. :P On 5/16/09, Gustavo Alberto Navarro Bilbao wrote: > A silly question: ¿Can be compatible OGRE and COLLADA at the same time?. I > say that because I suppose that there is a great time and effort spent by > the realxtend and SIRIKATA' teams, working on, and many are expecting in > July for the new RX-NG and SIRIKATA, and > would be a pity not to make the already developed. > > Best regards > > > > 2009/5/16 Jani Pirkola > >> Immersive Education initiative (IEd) has decided in its Technical Working >> Group to support COLLADA as the format to transfer assets between >> different >> platforms. >> >> http://maxping.org/business/news/immersive-education-adds-support-for-realxtend.aspx >> >> To further support COLLADA, IEd and Khronos launched a contest for >> developing content using the format. >> >> http://maxping.org/business/real-life/champion-the-3d-web-using-collada.aspx >> >> Best regards, >> Jani >> >> 2009/5/16 Tommi Laukkanen >> >> Hello >>> >>> As custom viewers start to emerge I would like to point to Collada >>> specification as one format which could >>> be used to support freestyle models (meshes): >>> >>> This document describes the COLLADA schema. COLLADA is a COLLAborative >>> Design Activity that >>> defines an XML-based schema to enable 3-D authoring applications to >>> freely exchange digital assets >>> without loss of information, enabling multiple software packages to be >>> combined into extremely powerful >>> tool chains. >>> >>> The specification: >>> >>> http://www.khronos.org/files/collada_spec_1_4.pdf >>> >>> The schema: >>> >>> http://www.khronos.org/files/collada_schema_1_4 >>> >>> -tommi >>> ___ >>> 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] voice meetings
Mike Dickson wrote: The only obvious problem to voice for some of these conversations is that if you're not there at the time it happens you lose out. No way to archive them (easily) for historical purposes or simply for those who can't contribute at the time the conversation happens. Since in many cases these are design discussions I think there's benefit to that record. freeswitch can record/stream MP3... Of course there's a way around that. If you do a voice meeting just publish notes from the discussion. That will help to foster communication and increase the level of participation rather than be exclusionary. In that scenarios its a win-win for everyone. Mike On Sat, 2009-05-16 at 18:23 +, Charles Krinke wrote: Indeed, discussing these subjects with those on the opensim-dev mailing list in voice or text is to all of our mutual advantage. Many folks have complained to me of the way the money issue was handled and communication with the rest of the community is important to moving forward and helping credibility. Charles ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- dr dirk husemann math & computer science ibm zurich research lab RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ SL: drscofi...@xyzzyxyzzy.net - http://xyzzyxyzzy.net/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] Test asset server / connectors
Just to illustrate the possibilities that this new software architecture enables, I have set up an asset server at UCI that can be used by hybrid sims out there. It will be on for the next couple of days, if you want to try it out. This is for illustration purpose only, I don't plan to run an asset storage business at UCI :-) If you follow the instructions below you end up with a mostly standalone grid that happens to be using a remote asset server. This kind of arrangement is already used by the Groups service made by mcortez. The new software architecture generalizes this to all services used by the simulators. Check out opensim, copy OpenSim.ini.example to OpenSim.ini, and set the new configuration variables at the bottom like this: [Modules] ; Choose one ;AssetServices = "LocalAssetServicesConnector" ;; = USE THE REMOTE ONE = AssetServices = "RemoteAssetServicesConnector" ;AssetServices = "HGAssetBroker" ; If you don't want asset caching in the regions, comment this AssetCaching = "CoreAssetCache" [AssetService] ; Parameters for local assets, formerly known as "standalone" LocalServiceModule = OpenSim.Services.AssetService.dll:AssetService" StorageProvider = "OpenSim.Data.SQLite.dll" ;StorageProvider = "OpenSim.Data.MySQL.dll" ;ConnectionString = "Data Source=localhost;Database=opensim;User ID=opensim; Password=opensim;" DefaultAssetLoader = "OpenSim.Framework.AssetLoader.Filesystem.dll" AssetLoaderArgs = "assets/AssetSets.xml" ; Parameters for remote assets, formerly known as "grid" ;; = SET THIS UP LIKE THIS = AssetServerURI = "http://ucigrid03.nacs.uci.edu:9003"; ; Paremeters for the Hypergrid connector ; ignore ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] [INFO] New config variables
There were some changes -- there is a new asset server -- but you don't need to use this new one yet, you can continue to use the old one, or CableBeach's AssetInventoryServer -- it's all compatible. There will be more information about how to configure the new servers soon, but it's not so urgent; since these names are still in flux it's better to stay undocumented for now. John Sheridan wrote: > Diva, > A quick question but were there any changes to the config for the ugaim > that we need to be aware of or will the old settings still work? > > Thanks, :) > > - John > > > d...@metaverseink.com wrote: >> Thanks for staying away from svn head for the past day and a half. >> Tests indicate that head is relatively stable, and ready to be further >> tested in the wild. As usual, head should not be used in production >> grids, *ever*. >> >> We are starting to move OpenSim into a new software architecture. With >> it comes a new set of configuration variables that will eventually >> replace the old ones. As you update your simulators into these recent >> revisions (post r9562), you need to add these configuration variables >> to your OpenSim.ini, or it won't startup -- it will crash on the first >> action related to fetching assets. >> >> Here is a page documenting what these new variables are, and how to >> set them appropriately. >> http://opensimulator.org/wiki/Services_and_Service_Connectors_Configuration >> >> >> PLEASE NOTE that all names of variables in there may still change >> within the next couple of weeks, as we converge on vocabulary and >> tighten up the architecture. For that reason, I continue to urge >> people who don't need to be on the bleeding edge of OpenSim to stay on >> a stable release for another while. Head is 100% compatible with the >> older revisions, and with the existing UGAIM servers, so if you don't >> need to update, don't update. >> ___ >> 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] [INFO] New config variables
Diva, A quick question but were there any changes to the config for the ugaim that we need to be aware of or will the old settings still work? Thanks, :) - John d...@metaverseink.com wrote: > Thanks for staying away from svn head for the past day and a half. Tests > indicate that head is relatively stable, and ready to be further tested > in the wild. As usual, head should not be used in production grids, *ever*. > > We are starting to move OpenSim into a new software architecture. With > it comes a new set of configuration variables that will eventually > replace the old ones. As you update your simulators into these recent > revisions (post r9562), you need to add these configuration variables to > your OpenSim.ini, or it won't startup -- it will crash on the first > action related to fetching assets. > > Here is a page documenting what these new variables are, and how to set > them appropriately. > http://opensimulator.org/wiki/Services_and_Service_Connectors_Configuration > > PLEASE NOTE that all names of variables in there may still change within > the next couple of weeks, as we converge on vocabulary and tighten up > the architecture. For that reason, I continue to urge people who don't > need to be on the bleeding edge of OpenSim to stay on a stable release > for another while. Head is 100% compatible with the older revisions, and > with the existing UGAIM servers, so if you don't need to update, don't > update. > ___ > 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] [INFO] New config variables
Thanks for staying away from svn head for the past day and a half. Tests indicate that head is relatively stable, and ready to be further tested in the wild. As usual, head should not be used in production grids, *ever*. We are starting to move OpenSim into a new software architecture. With it comes a new set of configuration variables that will eventually replace the old ones. As you update your simulators into these recent revisions (post r9562), you need to add these configuration variables to your OpenSim.ini, or it won't startup -- it will crash on the first action related to fetching assets. Here is a page documenting what these new variables are, and how to set them appropriately. http://opensimulator.org/wiki/Services_and_Service_Connectors_Configuration PLEASE NOTE that all names of variables in there may still change within the next couple of weeks, as we converge on vocabulary and tighten up the architecture. For that reason, I continue to urge people who don't need to be on the bleeding edge of OpenSim to stay on a stable release for another while. Head is 100% compatible with the older revisions, and with the existing UGAIM servers, so if you don't need to update, don't update. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] voice meetings
The only obvious problem to voice for some of these conversations is that if you're not there at the time it happens you lose out. No way to archive them (easily) for historical purposes or simply for those who can't contribute at the time the conversation happens. Since in many cases these are design discussions I think there's benefit to that record. Of course there's a way around that. If you do a voice meeting just publish notes from the discussion. That will help to foster communication and increase the level of participation rather than be exclusionary. In that scenarios its a win-win for everyone. Mike On Sat, 2009-05-16 at 18:23 +, Charles Krinke wrote: > Indeed, discussing these subjects with those on the opensim-dev > mailing list in voice or text is to all of our mutual advantage. > > Many folks have complained to me of the way the money issue was > handled and communication with the rest of the community is important > to moving forward and helping credibility. > > Charles > ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
