[Opensim-dev] ANNOUNCEMENT: justincc now a freelance OpenSim consultant
Hi folks. I hope you'll indulge me in using up my spam allocation for this year. But I just wanted to publicly announce that as of this month I'm now a freelance OpenSim consultant, ready to contribute to people's projects or give various kinds of advice. For more details, please see my blog post at http://justincc.org/blog/2009/09/17/im-now-a-freelance-opensim-consultant/ Best Regards, -- justincc Justin Clark-Casey http://justincc.org ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] scene import/export to another app: oar? dotscene? collada?
Shack, Have you read http://opensimulator.org/wiki/OpenSim:Xml_Serialization page? Also, Adam F authored (?) an orphaned page http://opensimulator.org/wiki/Xml_Objects_Format that I'm wondering what it's about? /Stefan > -Original Message- > From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- > boun...@lists.berlios.de] On Behalf Of Shack Dougall > Sent: den 17 september 2009 17:28 > To: opensim-dev@lists.berlios.de > Subject: Re: [Opensim-dev] scene import/export to another app: oar? > dotscene? collada? > > I'm excited to see this discussion and would just like to mention the > HPA format (Hierarchical Prim Archive) which is what Prim Composer for > 3ds Max uses to store its scenes. > > https://liferain.com/projects/hpa/ > > When I started Prim Composer, I looked at the existing formats such as > OAR and rejected them because they were too closely tied to the server > implementation. For example, one of the many problems with the > server-centric encoding is that it is much harder than it needs to be > to > determine the type of a prim. There isn't a single field that says, > "This is a box". Also, some prim fields such as taper have different > definitions depending on what type of prim it is being applied to. > > HPA is the alternative XML format that I came up with. It stores the > data using the client-side values that are presented to the user and > allows a hierarchical scene graph. > > It's not complete (e.g., it doesn't describe task inventory yet) and > I'm > not claiming that it is perfect, but it *is* very well documented. It > might be useful as a starting point and I'm more than willing to make > changes to it and update the documention accordingly. > > It uses the file extensions .hpa for the XML data files and .hpz for > the > zipped archive. I haven't implemented the zipped archive in Prim > Composer yet, but it is the logical extension of the current > specification and would give you something similar to an OAR file that > could be passed around easily. > > Toni Alatalo wrote: > > Justin Clark-Casey kirjoitti: > > > >>> I've now been leaning against writing OAR support elsewhere exactly > >>> 'cause it is the internal structure and perhaps awkward for what > need > >>> > >>> > >> That's theoretically true, but I should think that the old format > will still be > >> loadable in some way since changes here would break everybody's > existing content > >> > >> > > > > Yah was thinking about the same - I guess there are ways to deal with > > that .. perhaps kind of loosing the initial comfort of automatic > > serialization though, needing manual processing for backwards compat. > > > > > >> Separate files for objects and assetes were used in order to > potentially allow > >> regions to be more easily composed out of world from separate > components. > >> Whether this is a good thing or whether there are more advantages to > a single > >> monolithic file is, I'm sure, something that could be debated. > >> > >> > > > > Agreed - I think assets in separate files easily make sense, and for > > SL/Opensim like prims too 'cause there is no distinction of the > specific > > geom and it's instance(s) in the scene. That said the single file > > Collada .dae files that am working with now seem sensible too. > > > > > >>> Collada and X3D would be engine independent standards that would > >>> > >>> > > > > I built something called 'ColladaDotNet', using the Collada Document > > class from the Collada for XNA project, and have succesfully tested > > using that to read reference Collada scene files, and my own exports > > from Blender. > > > > Am planning to test importing scene info to Opensim / ModRex using > that > > .. first just object positions. May test in the Naali viewer (first) > too > > .. reading collada files there for local preview (may use with the > > pycollada lib there, have the same test as for ColladaDotNet working > now > > with that too). > > > > ~Toni > > > > > Toni Alatalo wrote: > > > > > Hi, > > > > I started looking into implementing scene exchange between > Opensim and > > Blender yesterday, and am planning to continue later today. Was > reading > > OARs and the code in > OpenSim.Region.Framework.Scenes.Serialization .. > > where SceneObjectPart #region XML Schema seems to be the fields > that are > > autoserialized by some .net writer, right? > > > > It seems well possible to read and write OAR elsewhere, but I'm > not sure > > if it makes sense, or whether it's more the internal > representation in > > Opensim. Are there any alternatives? With Ogre we've sometimes > used the > > simple DotScene (.scene) made for it, and basically that would > cover the > > info I'm interested in now (positions of meshes in a scene, not > prim > > geom 'cause am not having prims in Blender at least right now > anyway). > > There is an existing DotScene exporter for Blender, woul
[Opensim-dev] OpenSimulator.org Wiki Editor Upgrade!
I just wanted to let everyone know that a new Wiki editor has been installed into the OpenSimulator.org Wiki. The FCKWiki editor should make everyones lives editing the wiki much easier, the default editor is still available, and in fact still the default editor, but, now when you edit wiki pages you will be presented at the top of the editor with the chance to launch the "Rich Editor" which gives you a nice WYSIWYG editor, much nicer for formatting tables and having the page look like you want without several hours of searching wiki formatting rules. I would love to hear any feedback people have about the new Editor and also about the wiki in general, I would like to hear how everyone things the wiki could be better and easier to use, my next goal is to find a suitable search engine replacement for the wiki as we all know how terrible the current search works, Dave Coyle recommends if your having trouble using the wiki search to just use the google search engine and to enter your search something like this into the google search engine " "site:opensimulator.org/wiki " I have tried this and it works well, im looking into possible google search engine integration into the site, but wondered if anyone has better suggestion? Thanks everyone hopefully this allows us to start cleaning up the wiki more, Fly-Man- will be holding wiki meetings on Friday at 11am PST time, if you would like to attend and be part of the wiki cleanup team please contact him on IRC for more details. -- Michael Emory Cerquoni - Nebadon Izumi @ http://osgrid.org ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] scene import/export to another app: oar? dotscene? collada?
Thanks for the link Shack, it looks pretty cool - hopefully I'll get the opportunity to take a look soon myself and maybe make some comments. Shack Dougall wrote: > I'm excited to see this discussion and would just like to mention the > HPA format (Hierarchical Prim Archive) which is what Prim Composer for > 3ds Max uses to store its scenes. > > https://liferain.com/projects/hpa/ > > When I started Prim Composer, I looked at the existing formats such as > OAR and rejected them because they were too closely tied to the server > implementation. For example, one of the many problems with the > server-centric encoding is that it is much harder than it needs to be to > determine the type of a prim. There isn't a single field that says, > "This is a box". Also, some prim fields such as taper have different > definitions depending on what type of prim it is being applied to. > > HPA is the alternative XML format that I came up with. It stores the > data using the client-side values that are presented to the user and > allows a hierarchical scene graph. > > It's not complete (e.g., it doesn't describe task inventory yet) and I'm > not claiming that it is perfect, but it *is* very well documented. It > might be useful as a starting point and I'm more than willing to make > changes to it and update the documention accordingly. > > It uses the file extensions .hpa for the XML data files and .hpz for the > zipped archive. I haven't implemented the zipped archive in Prim > Composer yet, but it is the logical extension of the current > specification and would give you something similar to an OAR file that > could be passed around easily. > > Toni Alatalo wrote: >> Justin Clark-Casey kirjoitti: >> I've now been leaning against writing OAR support elsewhere exactly 'cause it is the internal structure and perhaps awkward for what need >>> That's theoretically true, but I should think that the old format will >>> still be >>> loadable in some way since changes here would break everybody's existing >>> content >>> >>> >> Yah was thinking about the same - I guess there are ways to deal with >> that .. perhaps kind of loosing the initial comfort of automatic >> serialization though, needing manual processing for backwards compat. >> >> >>> Separate files for objects and assetes were used in order to potentially >>> allow >>> regions to be more easily composed out of world from separate components. >>> Whether this is a good thing or whether there are more advantages to a >>> single >>> monolithic file is, I'm sure, something that could be debated. >>> >>> >> Agreed - I think assets in separate files easily make sense, and for >> SL/Opensim like prims too 'cause there is no distinction of the specific >> geom and it's instance(s) in the scene. That said the single file >> Collada .dae files that am working with now seem sensible too. >> >> Collada and X3D would be engine independent standards that would >> I built something called 'ColladaDotNet', using the Collada Document >> class from the Collada for XNA project, and have succesfully tested >> using that to read reference Collada scene files, and my own exports >> from Blender. >> >> Am planning to test importing scene info to Opensim / ModRex using that >> .. first just object positions. May test in the Naali viewer (first) too >> .. reading collada files there for local preview (may use with the >> pycollada lib there, have the same test as for ColladaDotNet working now >> with that too). >> >> ~Toni >> >> > Toni Alatalo wrote: > > > >> Hi, >> >> I started looking into implementing scene exchange between Opensim and >> Blender yesterday, and am planning to continue later today. Was reading >> OARs and the code in OpenSim.Region.Framework.Scenes.Serialization .. >> where SceneObjectPart #region XML Schema seems to be the fields that are >> autoserialized by some .net writer, right? >> >> It seems well possible to read and write OAR elsewhere, but I'm not sure >> if it makes sense, or whether it's more the internal representation in >> Opensim. Are there any alternatives? With Ogre we've sometimes used the >> simple DotScene (.scene) made for it, and basically that would cover the >> info I'm interested in now (positions of meshes in a scene, not prim >> geom 'cause am not having prims in Blender at least right now anyway). >> There is an existing DotScene exporter for Blender, would it make sense >> to write an importer to OpenSim? Or a Collada scene importer perhaps? I >> haven't looked (yet) what the scene format there looks like. For the >> Ogre format there is a 15 line complete scene example at >> http://www.ogre3d.org/wiki/index.php/DotScene >> >> In one way the question is: does OAR loading work wit
Re: [Opensim-dev] scene import/export to another app: oar? dotscene? collada?
I'm excited to see this discussion and would just like to mention the HPA format (Hierarchical Prim Archive) which is what Prim Composer for 3ds Max uses to store its scenes. https://liferain.com/projects/hpa/ When I started Prim Composer, I looked at the existing formats such as OAR and rejected them because they were too closely tied to the server implementation. For example, one of the many problems with the server-centric encoding is that it is much harder than it needs to be to determine the type of a prim. There isn't a single field that says, "This is a box". Also, some prim fields such as taper have different definitions depending on what type of prim it is being applied to. HPA is the alternative XML format that I came up with. It stores the data using the client-side values that are presented to the user and allows a hierarchical scene graph. It's not complete (e.g., it doesn't describe task inventory yet) and I'm not claiming that it is perfect, but it *is* very well documented. It might be useful as a starting point and I'm more than willing to make changes to it and update the documention accordingly. It uses the file extensions .hpa for the XML data files and .hpz for the zipped archive. I haven't implemented the zipped archive in Prim Composer yet, but it is the logical extension of the current specification and would give you something similar to an OAR file that could be passed around easily. Toni Alatalo wrote: > Justin Clark-Casey kirjoitti: > >>> I've now been leaning against writing OAR support elsewhere exactly >>> 'cause it is the internal structure and perhaps awkward for what need >>> >>> >> That's theoretically true, but I should think that the old format will still >> be >> loadable in some way since changes here would break everybody's existing >> content >> >> > > Yah was thinking about the same - I guess there are ways to deal with > that .. perhaps kind of loosing the initial comfort of automatic > serialization though, needing manual processing for backwards compat. > > >> Separate files for objects and assetes were used in order to potentially >> allow >> regions to be more easily composed out of world from separate components. >> Whether this is a good thing or whether there are more advantages to a >> single >> monolithic file is, I'm sure, something that could be debated. >> >> > > Agreed - I think assets in separate files easily make sense, and for > SL/Opensim like prims too 'cause there is no distinction of the specific > geom and it's instance(s) in the scene. That said the single file > Collada .dae files that am working with now seem sensible too. > > >>> Collada and X3D would be engine independent standards that would >>> >>> > > I built something called 'ColladaDotNet', using the Collada Document > class from the Collada for XNA project, and have succesfully tested > using that to read reference Collada scene files, and my own exports > from Blender. > > Am planning to test importing scene info to Opensim / ModRex using that > .. first just object positions. May test in the Naali viewer (first) too > .. reading collada files there for local preview (may use with the > pycollada lib there, have the same test as for ColladaDotNet working now > with that too). > > ~Toni > > Toni Alatalo wrote: > Hi, > > I started looking into implementing scene exchange between Opensim and > Blender yesterday, and am planning to continue later today. Was reading > OARs and the code in OpenSim.Region.Framework.Scenes.Serialization .. > where SceneObjectPart #region XML Schema seems to be the fields that are > autoserialized by some .net writer, right? > > It seems well possible to read and write OAR elsewhere, but I'm not sure > if it makes sense, or whether it's more the internal representation in > Opensim. Are there any alternatives? With Ogre we've sometimes used the > simple DotScene (.scene) made for it, and basically that would cover the > info I'm interested in now (positions of meshes in a scene, not prim > geom 'cause am not having prims in Blender at least right now anyway). > There is an existing DotScene exporter for Blender, would it make sense > to write an importer to OpenSim? Or a Collada scene importer perhaps? I > haven't looked (yet) what the scene format there looks like. For the > Ogre format there is a 15 line complete scene example at > http://www.ogre3d.org/wiki/index.php/DotScene > > In one way the question is: does OAR loading work with 'partial' data, > or would I have to make the exporter write all the fields? Am now > looking into exchanging this data first: > 123129.5529.340004 > 000 > 0001 > 17.777422.802869.2987 > > and things like velocity would not apply .. also, are valid region
Re: [Opensim-dev] lslc project
d...@metaverseink.com wrote: > Alan Webb's commit of today introduced a new project called lslc that > smells like it was by accident. Just checking. > If it's intentional, I think that code needs cleaning up on names -- > should probably be called OpenSim.Tools.Lslc. > What's the inside scoop on this? > it's intentional. re naming, fine with me. cheers, dirk > ___ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] [Opensim-users] OpenSim defaults now ODE and Meshmerizer
Justin Clark-Casey wrote: > As of revision 077d01c2255009a1e47e8bed42375ce81b770ef9, the default physics > engine in OpenSim is ODE and the default meshmerizer is Meshmerizer. > > I have added a note to > > http://opensimulator.org/wiki/Configuration#Running_OpenSim_in_64_bit_Windows_on_the_future_0.6.7_release > > about the need to use OpenSim.32BitLaunch.exe on 64 bit Windows. That > document > sure is a mess though. > > Thanks to all for their feedback on this topic. > and 077d01c2255009a1e47e8bed42375ce81b770ef9 translates into r/10722 :-) -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
