On ma, 2011-01-17 at 20:52 -0800, Edgar Santos wrote: > Actually I managed to do it via importing an ogre scene. There were > some problems but one of the most dificult ones to detect was that the > textures in the material file ended in capital ".JPG" instead of > ".jpg".
Oops. Is this in the modrex server side importer, or all over? Definitely a bug to fix. > About the world building mode, I know that each slot is for a material > but the problem is which order to put them! Right - the slots don't have names of anything like that in Ogre (nor e.g. Blender), they are just a list. When bringing from Blender (and I supposed the same applies for Max and Maya), we can check from the UI in there which material index is which. This can indeed be a problem with Sketchup if it doesn't tell you that. > Anyways, i could do it via "scene importing" so it is ok i guess. I > still think you should write some tutorial or something to help other > people do it, since they need to write (a rather simple) scene file ;) Yep certainly much better to bring the material assignments automatically. A correction to my previous mail: it wasn't last week, but actually already 2 months ago or so when importing local mesh files with automatic assigning of the material refs, and texture refs in the material, was implemented in the development version. So it is included in the Tundra 1.0 preview pre-release from December. You can test if that works for you: just run server.exe to get an empty scene (you see just white), and drag&drop a mesh from your filesystem to the Naali/Tundra window. There is one limitation when importing a single mesh: the material for it must be defined in a file that has one material only. You can do the same drag&drop with .scene files in Tundra, and that supports reading multiple materials from a single material file like current Naali releases and Taiga (opensim+modrex) do too. Unlike the Linden protocol, Tundra works so that the client side can also create entities, so when connected to a server such drag&drop to import a mesh is synched among all participants and separate publish step is not needed. So if we get that new technique to use for all of you, that workaround of making a .scene for a single .mesh is not needed anymore. The question is: can you use Tundra as is, instead of Taiga, for your application? If yes, you can just start using this easier authoring workflow. We will hopefully iron out some wrinkles in how the asset refs work there, but at least with absolute http refs you can already publish worlds on the net. If not, I think it would be great to support similar mesh drag&drop in Naali against Taiga too. Loading a single mesh for local preview actually just works, that's how the dotscene loading does it under the hood. Then for publishing to the server, the publish code could make that dotscene-with-single-mesh xml automagically for you (the scene import tool in Naali releases already has the code to write a new dotscene file, 'cause it can save the placement changes you do). I think this could be added in a day. Feedback is welcome for work priorisation considerations. In the meantime, please anyone feel free to write tutorials of current working processes like this. I think I'll personally at least keep focusing on programming so the tutorials would get shorter later on :) We've now been working on a demo using Tundra and testing it on a live server etc., seems ok so far -- unfortunately the models for that demo are not public yet so it needs to remain a bit hidden for a while still. We could and I guess should set up more servers with the simple public demos (included in the preview release so you can test them locally) hosted in the meantime. > Edgar ~Toni > On Jan 14, 4:00 pm, Toni Alatalo <t...@playsign.net> wrote: > > On Jan 4, 2011, at 1:06 PM, Edgar Santos wrote: > > > > > When I try to import the mesh to naali, the mesh is loaded without any > > > material. Then, when I attach the material file, nothing happens. With > > > some other meshes, it only reads the first material. Even if i > > > > Yes, the 'world building way' is limited so that from every material file, > > only a single material is used. > > > > > separate the materials in several files, there is no way to tell which > > > material slots correspond to the right material files. Also, I > > > > Build mode should show an input box for every slot, so you can assign them > > correctly there. > > > > > couldn't see any textures... is uploading them enough? > > > > Unfortunately not -- the Linden / OpenSim asset system works with UUIDs, so > > in order for the materials to point to the textures, they must use the > > UUIDs to refer to them. The UUIDs are created on the server when you upload > > the textures. > > > > > Finally, I tried to do this another way. I wrote an ogre scene file > > > that contained only my mesh object as a node. When I imported it, it > > > loaded the mesh and the materials, but the server still complainted > > > > Yes, this is the sane way, because it does everything for you and there is > > no hunting of UUIDs and reassigning materials etc. We should support it for > > single meshes without needing a dotscene file, and I think there's some > > work done for that in the development versions, but in current releases > > (including 0.4) what you did with that scene file is exactly the trick. > > > > Did you publish the scene on the server? > > > > The scene import tool in Naali works so that it first loads the dotscene to > > Ogre in the viewer directly, without using the asset system. This way the > > ogre way of referring to the materials and textures just with filenames > > works. But this step is only a local preview of the scenepart imported -- > > nothing is uploaded to the server yet. > > > > Then you have to fill in the form for publishing, enter the target region > > name at least (it doesn't default to current region automagically now, > > should I guess), and press the publish button. It then makes a zip of the > > scene + all meshes, materials and textures referred in it. That zip is sent > > to server with http, and processed there so that it creates Opensim assets > > of all the data and puts the resulting UUIDs as references to the right > > places. > > > > > about some missing material UUIDs... oh, and when I restart the > > > viewer, i stop seing the attached materials again, either with the > > > load scene trick and the normal world building way. > > > > If this was also with the dotscene publishing, getting the server log would > > be helpful to know what exactly happened there with the material asset > > creation etc. > > > > The 'blender way' Cecil referred to is this same dotscene zip upload route. > > With the more integrated b2rex tool with the difference that there the > > UUIDs for scene object instantiations, meshes and textures are created in > > Blender already, so you can non-destructively upgrade an already uploaded > > scene on the server with a new export from Blender (e.g. if you just move > > an object, it only changes the position of that object, so scripts etc. > > attached to it stay and no new assets are created). > > > > > Edgar > > > > I hope this helped, please tell more of how things went > > ~Toni > -- http://groups.google.com/group/realxtend http://www.realxtend.org
