|
|
|
Got it compiled now, few issues though i mentioned on sldev.
I compiled the mesh_1_1_patchfile from http://jira.secondlife.com/browse/VWR-6199
 with MSVS2008 Express against 1.21.6 and I've had the following experience:
(FYI, my interest (as Mike knows) is mostly as a machinimator who wants to manipulate the facial expression morphs so they can be more useful as dramatic expressions.) Before I went to the trouble of modifying an emote mesh exported from this client, I decided to try and import it after export just to be sure I had everything working. So I went: Advanced>Character>Meshes & Morphs>headMesh>headMesh>Express_Embarassed_Emote>Save OBJ I have two observations which are really questions I hope to resolve: 1. The new mesh seems to have "shrunk" my head. See the attached picture. 2. I was expecting it to replace the "emote" part of the avatar definition, so that when I get to the stage of modifying the meshes, I won't see the modified mesh unless I make my avi emote in a way that would have used a standard emote mesh. But in fact, it replaces the base head mesh. And it does so in a way that mostly negates the slider values for my head shape. I tried making my base head with 50's on all the sliders, thinking maybe it was a sizing issue (my avi has a big head Then I also noticed that using a female avi the line around the neck becomes a hair-breath crack. I tried to look at the source code changes from a previous patch for this, but there were some spacing changes and I couldn't create an automated diff-check (my skill here is very minimal). But it does look like there were some significant menu changes to perform LLM saves, and that might have destabalized an earlier version that might have been working better. I'm posting an earlier version of Mike's patch which I'm calling mesh 1.0.
Afer compiling it, I discoverd 1.0 actually does what I believe Mike originally intended. It seems that as he was fixing some bugs and adding a very significant feature – saving the mesh in LLM format (truely amazing!!! ) – he inadvertently created a bug that imposes the loaded mesh as the base mesh and also has a kind of 'shrinking effect' when the loaded mesh is an emote. I'm sure Mike will be fixing this very soon, but since I'm finding his earlier patch to be a useful tool, I am posting it to this JIRA in case someone else is burning Christmas-Weekend oil on this. Best wishes and Happy New Year to all. Vector PS: Now that patch 1.2 is up, I'm taking down 1.0. I've uploaded screenshots for the settings that seem to work in Blender to import/export the .obj files exported/imported from Mike's mesh1.0 viewer.
I think it's also important to limit the kinds of editing done inside Blender, don't move it or it actually will be displaced when imported to your avatar (though this can be used to make body parts 'disappear' from local view). It's also important, as Mike states, to only move around the points in the mesh – don't delete or reorder any of them. In playing with head emote meshes, and using these settings, I notice that they are significantly smaller than the originals exported from mesh1.0. I haven't found the problem that might come from this... yet. Ok, from a release build patch 1.2 crashes immediatly when i try to click the mesh and morphs option without a specific reason, strangly when i did a debug build it worked just fine, did a release build again to make sure and it 'did' crash.
Bummer, Khyota. Sounds like you can work with it, but if you need a rel-with-debug binary, it's here:
My apologies though, I'm toying with a MSVS2008 environment, and the sound on this binary doesn't work when plopped into a 1.21.6 directory tree. I haven't taken the time yet to figure out why. So far for me, 1.2 fixes all the bugs in 1.1. There's menu options from 1.0 which are missing in both 1.1 and 1.2 which I sent to Mike (you can't load obj files into the LOD meshes). Now if I can only figure out why loading Express_Closed_Mouth as the base head mesh makes the lips pucker, I'd be a happy clam. Im working from Linux though, I specify custom CXXFLAGS with -march=athlon64 -O2 -msse3 -pipe (i doubt sse3 adds any optimization though) for Release too so i wonder if thats part of the issue. Im about to do one with the default.
Khyota, I've been doing release with debug builds in VS2005. I'll try a release build.
Vector, the reason that loading Express_Closed_Mouth as the base mesh doesn't work is that the Emotes are not applied directly to the base mesh. They are instead blended with the Express_Closed_Mouth morph before applying because the base mesh has an open mouth. So by making the closed mouth the base mesh, you really apply it twice. It is really a hack and prevents emotes from blending properly with each other. I don't know why Linden did that instead of just changing the base mesh. The way out of the problem is to save all of the morphs as OBJ files, load the closed mouth as the base mesh, and then reload all of the morphs. I hope to make an LLM file with this done, but I want to get an exact match on the binormals first. Right now the binormals (which have to be computed for OBJ files) are close, but not exactly the same as the original ones. The reason you can't load obj files into the LOD meshes is that LOD meshes just reuse a subset of the base mesh vertices but define new faces. Since I'm not processing the OBJ face commands yet, there is really nothing to load. The reason that it appears as a menu option first, then a floater, and then a submenu is because the Advanced menu is created before the meshes and morphs are loaded, so the Meshes and Morphs menu cannot be created at the same time. So when you select the menu option, the Meshes and Morphs menu tree is created dynamically and immediately torn off so it's easier to use. Then when you close the tear off (which is a floater) the menu tree attaches back to where it was torn off.
Thanks for the stack traces. I'll have a look at it when I can. I tried a Release build and I do not see the crash, but your traces should give me enough information. It's a little curious, though, that some addresses for "this" are 32 bit and some 64 bit. Do you usually see that? Mike, that's FANTASTIC!!! I did the work-around you mentioned – it works great.
I never thought to reload the base pose since I guess I was thinking the deltas were calculated dynamically from the stored meshes. Now I probably properly understand that meshes are stored as deltas from the base. Obviously, that saves math in the client. I don't have my audio equipment where I'm working, so I can't test out the lip synch with the .llm configured this way... on the lip sync wiki you wrote: "So, we add the negative of the Express_Closed_Mouth to Lipsync_Ooh and Lipsync_Aah to get the same effect as the emotes and then we don't have to blend to a default." Will this cause a problem? Or when we load base_mesh = Closed_Mouth will the Express_Closed_Mouth information now be all zero, so the negative will be zero? I know experimentation will tell, but I won't be able to run that experiment for over a day. I'm so very, very excited. Thank you Mike! Yes, Vector, when you load the base mesh as closed mouth and then reload the closed mouth emote, the closed mouth emote morph will be zero and emotes should blend much better. The problem, though, is that all of the morphs are relative to the base mesh. So it's not just the emotes that need to be reloaded.
However, it does not affect all of the morphs because most morphs only store the deltas for vertices that are changed. So any morphs that affect the mouth will have to be reloaded. The Lip Sync morphs, though, are already relative to the closed mouth, so they need not be reloaded. And there's another catch. Some morphs (for reasons not at all clear to me) store all of the vertices. Those will also have to be reloaded. You should be able to see which those are by looking at the min and max images in the Appearance window. If you see the puckering in the minimum image, then the corresponding morph would need to be reloaded. Yeah, I know it's confusing. Feel free to ask for clarification. Khyota - is that a release-candidate branch build? That sounds like a bug that existed on that branch for a couple of days, though it should be fixed now.
Im using trunk, although the 1.22 branch did merge recently, could that be why?
Khyota, mesh_1.3.patchfile will fix your crash. The program was trying to blink the menu item that created the mesh and morph menu tree. That item was already removed and hidden. On my system and on yours with a debug compile, it took longer than the blink time (0.3 seconds) to create the tree, so by the time it was looking to blink, the time had expired. In your release build (on your computer which is obviously much faster than mine :-< ) it finished building the tree in less than 0.3 seconds and tried to blink, but promptly crashed.
Perfect! great we got that bug solved
 Still toying around with upper body base now, Its excepting simple changes withought any issues, using the blender import/export options vector provided, also the import in SL is compatible with exports of Domino Marama's avatar mesh at http://dominodesigns.info/ ! as long as you do not select Rotate X90. Also it does not seem to accept the mesh if the vertices have been moved extremely unrealisticly, dont know if thats a bug or a feature.
Eventually i want to use this to change the SL human mesh into a 'furry' shape, this will be quite a challenge to do it withough removing/adding any vertices. What else do you plan on incorporating in this feature Mm? Thanks for the great work! Re: the min-max morphs. I think I understand what you're telling us Mike. Thanks. I haven't seen that effect in the two avi's I'm testing with. I'll make a pass through with one maxing and minning the sliders so that the .llm I create won't have that problem – 'cause I'm sure once I think I'm done, I'll buy some body shape that maxes some parameter out and messes up the mouth. :-\ (actually, now that I think about it, it might actually be easier and more through to just reload every single head-mesh – once you're happy with the llm you're creating.)
That's great news about the lip-synch. Much less to do! I had a similar thought to Khyota's: making furry shapes with this that are much more lifelike. (I have a dragon script that almost sold...) But for that to work for movies, I'd want to be able to have humans and furries interacting... Just brainstorming here, and since Tofu is listening, Is there anyway to segregate the mesh into biological types? Is it bifurcated male/female now? (That could work: use male for a non-human species and make all the humans female with flat-chested women as stand-ins for men. Being able to modify the meshes could allow transcending any limits on making men out of women-shapes.) I fear, though, that your answer will be there's one base mesh, and no way to plug in other biologies without a server mod. And does modifying the bones require server-side changes? Anyway, just thinking about possible futures. I have to say, I'm having a blast working these things out with you guys!! "Eventually i want to use this to change the SL human mesh into a 'furry' shape, this will be quite a challenge to do it withough removing/adding any vertices. What else do you plan on incorporating in this feature Mm?"
The next step is to see if I can get the binormals to match the original values exactly, then to implement the face commands of the .obj files so that the .obj format restrictions aren't so strict. After that, I'll write an export function for an XML .llm file and an option in the .llm load to accept an XML file as well as the current .llm binary. Actually, the code looks like there once was such a load option. I'd like it to be the XML that Linden uses internally (see VWR-6198 ) but if I don't get that, I'll just make something up. Because much of the structure of the .llm file is defined in the avatar_lad.xml file, it's not possible to add morphs without changing both the .llm file and the avatar_lad.xml file. That's something that is better done by editing the text files. I'd also like to add a function, similar to the Appearance editor that could be used to create or adjust new Emote morphs by using sliders with either the current set of morphs or with any custom morphs that you may create. Which leads to the final goal. Avatar appearance is set by a vector of morph weights. My reading of the code so far is that that vector can be 255 elements long, but is currently only 218. That means that there's room for 37 new appearance morphs. And the number of allowable Emote morphs seems to be limited only by the viewer code, so any number of those could be added. The number of vertices could also be changed as long as the morphs and the base meshes use the same ones, so it is conceivable that Linden could publish a set of meshes and morphs where the current mesh becomes LOD1 and is the default, but a finer mesh could be set as an option if your hardware can handle it. But that will take time. "Is there anyway to segregate the mesh into biological types? Is it bifurcated male/female now? (That could work: use male for a non-human species and make all the humans female with flat-chested women as stand-ins for men. Being able to modify the meshes could allow transcending any limits on making men out of women-shapes.) I fear, though, that your answer will be there's one base mesh, and no way to plug in other biologies without a server mod."
There is only one base mesh. The male-female change is just a morph. I'm not sure why it's a radio button instead of a slider. Most of the code looks at the weight of the "male" morph and chooses the half-way point to determine the gender. Some of the morphs are restricted by gender with a parameter in the avatar_lad.xml file. This has more to do with making the Appearance editor sensible (or politically correct) than anything else. "And does modifying the bones require server-side changes?" I don't know. I haven't looked at them. It probably depends on the kinds of changes you make. Bones are used for animations, so that brings in a lot. Sharing violoation was my envrionment. If I run it as administrator on Vista, no problem replacing the llm in-situ.
Hooray for Mike! Question to the mesh master on importing on top of the altered base-mesh...
If I neglected to export all the appearance editor target morphs before loading closed_mouth into the base morph and saving as .llm, do I need to go back to a pristine llm before exporting the legions of target morphs that I'm going to re-import over closed_mouth to cancel any doubling? Or are the target morphs stored as absolute values relative to the original base mesh so that if I export after making a bunch of changes, then import, I'll get the same cancellation as going back to an original avatar_head.llm? Did that question make sense? Vector, if the morphs don't have vertices near the mouth, then they shouldn't be affected. Morphs have only deltas, and usually deltas of zero are not stored. However, to be safe, you should export the targets from the original .llm file, because sometimes they do store the zero deltas. Nevertheless, whatever you see in your 3D editor will be used to create the delta morph, so if it looks good there, it will look good in-world.
Does that answer make sense? RC branch merged back to trunk and caused this to break, crashes on startup with the patch applied, i got backtraces.
Program received signal SIGSEGV, Segmentation fault. lol. Thanks for your patience, mike. Yes, the answer makes a lot of sense. By altering the base mesh, I've potentially altered any other meshes with near-mouth vertices because they're the stored as diffs.
Khyota, that's why I never work out of the trunk code.
Someone decided to change the way menus work, so that instead of using pointers, you now have to use an LLHandle. Probably a Java programmer. Mike I'm happy for people to keep working towards this, but I wanted to give a status update - I can't picture this issue getting looked at (even a little) internally for many months, given our current priorities; this is pretty much way down the list.
That's OK. For a while I was waiting for the 1.22 series to go official, then other things came up. I'll get back to this soon.
It would be useful to get the related issue VWR-6198 looked at though. It's not much work; just a decision. Mike I wrote a program a couple of years ago that converts the *.llm files to an XML based format... I currently don't have easy access to it (it's on a HD in a storage locker). From the XML format it should be easy enough to dump it to any other format you want. The only reason I've never released it is that I wrote it prior to SL going open source (after which point it was like "Why would anyone want this, they can just read the source?").
Thanks, Strife. The goal is to get something that Linden would regard as the primary source of the mesh data. So that means that not only do you have to go from .llm to .xml (or whatever), you also have to go in the opposite direction. That means writing a compiler to convert the source version of the meshes into the .llm binaries. That's actually the harder direction. If Linden where to release their meshconverter, that part would already be done.
being able to maybe create an avatar shape off grid and then uploading this file to the grid would be jolly for me but what i would like to be able to do is create an avatar shape in-world and then somehow land up with an OBJ file that is correct for that shape. The advanced menu > character tests > save xml option actually doing something or getting a Poser file with the morphs would work.
Strife this program does it have the morph data included?? I'd love to see VWR-6198 resolved, but it's probably in a similar position (totally feel free to ping it though, there's some tiny chance that maybe it can easily ride the back of something else like the new opensource branch).
Robertltux, I belive what Mike has provided here does exactly what you want. Albeit, you'll need to paste together several meshes to get a complete avi.
Does anybody have a working binary copy with the patch builtin??
ive tried to spin up a source compile but all im getting is gibbering hash (note i will trade webspace for the file if needed) I've gotten access to the drive in the storage locker and will be releasing the tool as soon as I can get the drive in the computer (next couple days).
Just as a ping to folks a couple events
1 The Emerald Viewer (as of rev 1.23.4.904) has the 1.3 patch included Strife status on your tool?? |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Normal
Decompile avatar LLM mesh(es) back to their source format
1. It provides a menu structure created by selecting "Meshes And Morphs..." from the Advanced->Character menu.
2. Its primary purpose is to allow machinimators to modify the Emote morphs to build more expressive avatars.
3. A secondary purpose is to allow residents to export their current appearance meshes to 3D graphics editors in order to map textures better. I'd also be interested to see if it's possible to then import the mesh as a sculpty to make a mannequin.
The patch is applied to version 1.21.6 of the source code.
The meshes and morphs are saved as OBJ files which should be generally readable by 3D graphics programs, but they must be in exactly the same format to be loaded back into the viewer. The meshes at http://ccccybernetics.com/avatar_databank/
do not have the vertices or their coordinates in the proper order, and they contain duplicate normals and texture vertices, so they cannot be loaded correctly.
Vertices can only be modified; they cannot be added or deleted; and they must stay in the same order as written. There must be one normal and one texture vertex for each geometric vertex, and they must be in the same order. Face data is written, but it is currently not read because morphs use the same face information as the base meshes.
Internally, morphs are stored as deltas to the base mesh (an exception to this is the lip sync morphs which are stored as deltas to the default pose morph), but they are written out as full meshes. This means that you could change the base mesh and all of the morphs would apply to the new mesh. You wouldn't have to modify all of the morphs.
Since only your viewer loads any modified meshes or morphs, only you see the changes. Others will still use the meshes and morphs that they have. So if you'e recording machinima, the viewer used as the camera must have the modified morphs.
The changes only last as long as you are logged in unless you save them as LLM files. The menus give you this ability. If you save it with the same name as the original, the code will make a backup copy with the .bak file extension. Once a backup copy is made, it will not be made again, so that, unless you deliberately subvert it, the .bak copy will contain the original meshes and morphs.
I don't distribute a viewer, so it's up to others to actually provide binaries, but I'd be eager to help anyone who wanted to incorporate this patch.
Note that this patch incorporates the patch at VWR-11068. If that gets incorporated into the Linden code base, I'll put a new patch here.
Now I'm looking to see if I can modify the appearance editor to allow emotes to be created from existing morphs.
Any question or comments are welcome.
Mike