Well I understand your suggestion, but that solution is not valid for export a complex scene from, for example, 3DMax. If we have a complex scene, for example (I'm, talking about a real situation, then forced us to desestimate Taiga and to use OpenSim instead), a project submitted from a study of architecture, with seafront gardens, streets and buildings, all in a .max format, exporting in a scene format, using Ogremax, to create about 300-400 meshes, and that make impossible to assign the meshe collission in the way than you suggest. Because that our architects and designers are recreating all the project using SL-prims.
Thanks for your answer. Alberto 2010/5/31 Jonne Nauha <[email protected]> > If I recall correctly the collision mesh cant have submeshes, or they can > but only first is applied. This means that if you put the same mesh as > collision mesh only the first submesh will do collision. So the "area" of > the mesh that the first material affects too, is the first submesh. For > complex meshes that has many submeshes to set own textures you can simply > make a separate collision mesh of your model. When the mesh is done, combine > all the submeshes in your editor and export that separately, upload and set > as that collision mesh. > > Example: you have platform where you want to walk, with "risen side part" > submesh for best visual looks with its own texture. If you set the same mesh > you'll fall trough the platform part but can walk on the "sides" if its the > first submesh. > > Hope this helps. I dont think its too hard to make one mesh out of a > complex one as a separate collision mes in any editor :) > > Best regards, > Jonne Nauha > realXtend developer > > http://www.realxtend.org/ > http://www.evocativi.com/ > > > > On Mon, May 31, 2010 at 9:21 AM, Toni Alatalo <[email protected]>wrote: > >> Gustavo Alberto Navarro Bilbao kirjoitti: >> >>> Yes, I know that solution: to create a big and invisible meshe over the >>> other ones, but, in my opinion that is the kind of provisional solution than >>> in spanish we call "una chapuza", sorry but I don't know the english >>> definition. >>> >> >> No not as a separate object, but one(s) that you define as the *collision >> mesh* of the visual object. In the rex props tab, IIRC next to the where you >> assign the visual mesh, you can define that collision mesh used too. >> >> It is not a hack or some sort of cheap solution, it is how realtime >> content with collisions has usually been authored. >> >> >> That solution is good for visual aspects and no complex meshes, but if you >>> really would like to create and "inmersive" world and not only a "virtual >>> walktrought" one, that can't be the final solution, specially if we are >>> thinking about scripts to test wheels, engines and other perfomances in >>> simulations. >>> >> >> Err, there is no limit for the complexity or anything set by this route of >> having the collision object definition separate. Quite the opposite, it >> allows for more complexity, 'cause the visual mesh can be made for best >> visuality and the collision mesh for best collision features. >> >> Having the fallback where the visual geom is used also for collisions, >> when a separate collision mesh is not provided, is useful for quick/simple >> things but exactly more complexity is where you may need this feature that >> it is possible to use a separate one too. >> >> Alberto >>> >> >> ~Toni >> >> 2010/5/31 Toni Alatalo <[email protected] <mailto:[email protected]>> >>> >>> >>> >>> Gustavo Alberto Navarro Bilbao kirjoitti: >>> >>> I think that it would be very important to fix the issue of >>> physics in the meshes, when they have more materials, to be >>> cease to be "phantoms", >>> >>> >>> I suppose you know the current solution, from the earlier talks? >>> Use a collision mesh without several materials, for the visual >>> objects that have many materials. That's the reason why it has >>> been implemented like it is: collision meshes are often authored >>> separately, and as they are invisible anyway, there is no reason >>> for them to have materials, so the physics mesh creator didn't >>> need to support that. If you don't care / need to make a different >>> geom for the collisions (often many visual details are irrelevant >>> or even harmful for proper collisions), you can just make a copy >>> of the mesh where remove the mats in your modelling app. >>> >>> But I agree that for the fallback of using the visual mesh for >>> collisions too when a separate collision mesh is not provided it >>> would be a good idea for it to handle all the submeshes (material >>> indexes become submeshes in ogre). Probably quite simple to add in >>> rexode where the geom for ode is created. >>> >>> ~Toni >>> >>> >>> -- http://groups.google.com/group/realxtend >>> http://www.realxtend.org <http://www.realxtend.org/> >>> >>> >>> >>> -- >>> http://groups.google.com/group/realxtend >>> http://www.realxtend.org >>> >> >> -- >> http://groups.google.com/group/realxtend >> http://www.realxtend.org >> > > -- > http://groups.google.com/group/realxtend > http://www.realxtend.org > -- http://groups.google.com/group/realxtend http://www.realxtend.org
