On 11/08/10 07:26, Toni Alatalo wrote: > Pablo Martin kirjoitti: >> I packaged a new release for b2rex (blender exporter for realxtend), you >> can download it at: >> http://github.com/downloads/caedesvvv/b2rex/b2rex-0.2.zip >> > > Great news! > > A couple quick notes about technical things - might be a good idea to > continue about those on the -dev list to not make too much noise for > users who are not involved with all the underlying bits.
Ok, I'll try not to get too gory on details too. > >> For synchronizing the uuids, I've taken the route of storing uuids with >> blender objects and including an additional file on the uploaded pack >> holding the requested uuids. I had to modify the modrex ogre importer >> for this, the patch is included with b2rex code, and I would like to >> > > What about simply having the UUID as a new attribute in the <entity> > tag in the main .scene file? I had thought of making it that way, > seems simpler to handle than a separate file, but I haven't actually > tried. > > And yes all this is certainly targeted to be default functionality in > (mod)rex. Perhaps we move that to git(hub) now to ease collab, IIRC > Mikko Pallari was considering it already. For me it was a little bit easier to put the info in a separate file, although this can be changed of course, although the fact is there are uuids for materials, textures, meshes and objects (and I guess more objects, but these are the ones I keep track of right now), so these would have to go in different places if embedded in that way, so the export might be a bit more difficult at least for me, and in some cases might be that we don't have such a place, like with textures or materials, so the separate file approach makes it straightforward in both directions (since we already manage several metadata files anyways). > >> There is still one problem with the approach, though, and it is that I >> didn't manage to make changes to asset data propagate... I think opensim >> is not really updating this, so for the moment b2rex supports setting >> > > Is this perhaps due to the fact that in Second Life (tm) and therefore > in current Opensim assets are immutable? In SL traditionally there's > been mostly just texture assets in which case it makes sense (for easy > caching), 'cause prims are not assets and material settings are just > prim flags etc. With Realxtend and Ogre it's a whole different story, > with meshes and materials being assets also, materials pointing to > textures -- due to the asset immutability if you change a texture, you > have to create a new one, and then a new material that refers to it > etc. There's been talks about possibly changing that, but that's how > it is currently. Ok, I'll think about updating then, and I'll think about how to overcome the problem. For the moment, though, as b2rex allows to recreate the assets it already works ok to update objects, its just not so efficient as could be and also I'm not sure but I don't see the way assets get deleted from the db so I'm kind of worried :). > >> For the next release, I plan to work on character and animation support, >> also as time allows, I'd like to start work on synchronizing directly to >> naali, and improving any aspects you people think are important, I'd >> specially like to hear feedback on what materials people use or would >> like to use so we can work on making it easy for those. >> > > Right-o. We'll test and give feedback -- last I heard (from Evocativi) > the blocker for one modeller there was that in the very first version > of the dotscene export route (in December) normalmaps didn't work. Now > with the rex shader support for previews etc. we are well beyond that > I guess so interesting to hear how it fits what the people need. Yes, also I'd like to hear if people have any problems so don't hesitate to contact me directly on irc for support. Of course regarding materials we're well beyond normalmaps and at the stage of thinking what other techniques might be of interest, so even for people who cannot test right now just think what you would really like to have. My current material "wishlist" is adding some lower end techniques, non-cg techniques, and adding another layer for setting up an ambient occlusion map (or maybe this can be done with the luminance map but I didn't test it yet). More on the toy area, I'd like to try implementing steep parallax or something similar but I haven't tried. > One other thing we've discussed in planning this export stuff, > continuing with the idea of handling updates by keeping the UUIDs, is > allowing editing in-world too between two uploads from > Blender/Max/etc. An idea there is that perhaps we can specify what > data is authorative from the import, and what from what is in-world. > For example: > > 1. A modeller makes a first version of the scene, publishes on a server > 2. A scripter writes some logic and goes in-world and attaches script > references to some objects > 3. The modeller has improved the looks, and updates a new version > * the import in modrex could perhaps keep the script references > already put in 2., just update the mesh geom + textures etc > > This may get tricky but perhaps something sane is possible. Your use case would work out of the box with b2rex, since I think the ogre importer shouldn't destroy this kind of extra metadata when updating a world... although I'm not sure how scripts are stored yet. Anyways I also thought about this for similar use cases where it's really needed, like if people move the objects or switch object materials in-world for example, and started to prepare in a way. I've added an xmlrpc function on my modrex version that returns information about the scene objects, assets and materials (maybe there was some other functionality returning all this info, but I couldn't find one giving me what I wanted), so I can inspect the scene and import back some data, although I'm not doing it yet. I plan to use it soon for importing simple object metadata, later for more ellaborate synchronization. I can certainly import or maintain any kind of references and metadata, and with just a few xmlrpc or rest functions and some flags on blender side this should be possible to do cleanly. Cheers Pablo
signature.asc
Description: OpenPGP digital signature
