Jump to content

Psistorm Voxel

  • Posts

  • Joined

  • Last visited

Everything posted by Psistorm Voxel

  1. Thanks for the reply, good to know I wasn't being crazy - I may see what I can do about it, or simply stick with the default orientation. I appreciate the help!
  2. I've been tinkering with a custom day cycle for my homestead, but I've run into something I havent' been able to solve just yet. I would like the sun to be on an ecliptic plane rather than being a straight east to west orbit, so rather have the sun's plane be angled for a nicer effect, rather than the equatorial look. But While I can set the sun angle, things get weird once it reaches its highest point, there doesn't seem to be a good way to make it continue past its noon peak along said plane, it introduces some weird, fast movement at that point. Are there settings I am missing, or are there any good hints to make this happen? I greatly appreciate it! Also if there are obvious tutorials etc I missed, I apologize!
  3. That's some consolation at least, though I do hope that in the future we can have a full PBR bake stack to finally get rid of applier hell, and to allow things like glowy/metal/etc tattoos, bionic overlays, scale/fur applications etc etc - the possibilities would be endless!
  4. Thanks for the info. And I was worried about that, but hopefully makers can agree on a universal implementation. Maitreya never supported omega materials, belleza jake STILL glitches out its top half when applying omega, and legacy... I don't even know what they are doing anymore, but it just won't ever look like the other bodies. With everything in one material file, hopefully a standardized applier setup is coming. I'm just sad that PBR is not compatible with BOM, which means to have a PBR avatar, you MUST have drawcall heavy alpha sections again if you want any hope of mesh clothes
  5. As someone very much interested in switching to a PBR workflow, the big unknown is how will this affect mesh bodies? Has there been any talk at all about a standardized applier system (since from my JIRA attempts, a bake stack seems out of the question, which would have both solved SO many problems and enabled SO many cool things)? Or will it pretty much just be the same as before with omega, maitreya, legacy, ebody, etc all doing their own thing (and someone definitely wanting albedo maps as BOM because BOM good i guess)? Also can material parameters be exposed to be tweaked manually/via LSL? I'm genuinely excited either way, this will improve my work in many ways and make a lot of things easier for me, so learning about those implementations will help me prepare for either easy transition or applier hell, lol
  6. Yeah not sure why the tabbing was so messed up, realized it too late. I did try this and it helps, now I just need to figure out the pre-existing rotation part. Aka if the user rotates the object, that should be respected and tilts should be applied on top of that. But I should be at the point where I can figure that out pretty easily, so thank you! Edit: And solved the issue, thank you again! The respective code is here, formatted nicely this time: //obtain "natural" rtation of object without tilt angles rotation _rBaseRot = llEuler2Rot(<0, iTiltV, -iTiltH> * DEG_TO_RAD) * llGetLocalRot(); //Update tilt angles here //rotate first around local Z, THEN around local Y llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_ROT_LOCAL, llEuler2Rot(<0, 0, iTiltH> * DEG_TO_RAD) * _rBaseRot]); llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_ROT_LOCAL, (llEuler2Rot(<0, -iTiltV, 0> * DEG_TO_RAD)) * llGetLocalRot()]);A
  7. I've been trying to solve this issue for a little while now, the main issue is that the order of rotation for what I have in mind is problematic. To sum it up: An object is supposed to rotate first around Z, THEN around the Y axis but in its new, rotated coordinate system. So imagine you take an object in SL, twist it around Z, then set transforms to local, and twist it around local Y. This should technically be easy, BUT. This object is a) meant to be attached and b) ideally work in an already twisted coordinate system, so another rotation would be multiplied into this process, which is what makes this so complex. Because at the start of the transformation, I first have to factor out the previous Y/Z tilt angles to get a base rotation which might differ from 0/0/0, and THEN multiply any changed tilt values back into it again. I have a relevant code snippet here, I tried to first rotate around Z specifically, then take the existing rotation and add an axis angle rotation around the rotated Y axis, but it's not working at all for me. //rotation _rBaseRot = llGetLocalRot() / llEuler2Rot(<0, iTiltV, iTiltH> * DEG_TO_RAD); rotation _rBaseRot = llGetLocalRot() / llEuler2Rot(<0, -iTiltV, 0> * DEG_TO_RAD); _rBaseRot = _rBaseRot / llEuler2Rot(<0, 0, iTiltH> * DEG_TO_RAD); if (~llSubStringIndex(message, "tilth")) { if (message == "tilth") iTiltH = 0; else iTiltH += (integer)_sTarget; } else { if (message == "tiltv") iTiltV = 0; if (message == "tilt") { iTiltV = 0; iTiltH = 0; } else iTiltV += (integer)_sTarget; } llSetObjectDesc((string)iTiltH + ", " + (string)iTiltV); llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_ROT_LOCAL, _rBaseRot * llEuler2Rot(<0, 0, iTiltH> * DEG_TO_RAD)]); //llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_ROT_LOCAL, llGetLocalRot() * (llEuler2Rot(<0, -iTiltV, 0> * DEG_TO_RAD))]); llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_ROT_LOCAL, llAxisAngle2Rot(<-llSin(iTiltH), llCos(iTiltH), 0> * DEG_TO_RAD, -iTiltV * DEG_TO_RAD)]); Any sort of help on how to math this out better would be appreciated, I consider myself somewhat adept at scripting, but rotational math has always been a weak point of mine.
  8. Hmm, it shouldn't be related to an AO, I use pre-bento ones currently, and my animations only drive bento bones, so I think there should be no potential conflicts
  9. I've recently built a mesh avatar using Bento animations for hands, head, and tail. All in all I'm very satisfied, though I've come to notice that sometimes the animations just kind of stopped without any discernable reason. To start the animations, I have two triggers for on_rez and attach, the former querying llGetAttached() before starting an animation trigger permission request. Once the permissions have been granted, I scan the active animations for any leftover animations that each script can play, and if any are found, stop them so no stale animations can play through, say, a script reset or anything. After this cleanup, my animations are set to play. On animation switches - for facial expressions for example - I first stop the old animations that were playing, then start the new ones afterward. Other than that, there is no other stop logic, and yet, I sometimes realize that my animations have stopped seemingly on their own. Are there any other conditions - teleport, region change, etc - that can stop looping animations? I should also mention that I make use of single-frame looped animations as well, though they seem just as effected as my multi-frame looped animations.
  10. Hiya! I actually determined the cause of the joint offsets, and I'm sorry to say it was my fault all along! It turns out I majorly brainfarted and didn't assign any weights to lower/upper teeth, thus breaking the chain of weighted bones upon export. This explains why any weird offsets went away once I made sure the offset between jaw/teeth was the same as in the original skeleton. I just forgot to do some sanity checks it appears. As for the FBX files, I finally figured out why they come out looking different than the DAE files as well as what avastar provides. The FBX files aren't built based off the default shape, but have various sliders changed, most notably arm length, shoulders, neck thickness and head size, along with a few other minor tweaks. This explains the discrepancies I've been seeing between the FBX files and other skeletons.
  11. I'd like to bring up another issue I came across, something which does need addressing in an official form. The .fbx files provided on the official forums have certifiable flaws in them, most notably the issues seem to be stemming from mFaceTeethUpper and mFaceTeethLower, which appear to have some anomalous rotation applied to them, or they do not correctly respond to having offsets applied to them. My tests have been inconclusive other than the fact that they do not behave as expected, and as such create a lot of problems when trying to, say, construct an anthropomorphic head. The worse thing is that these errors do not present in the import preview, thus necessitating an upload each time to verify the correctness of the rig. Edit: I found a further bit of confusing information. The project bento skeleton guide found here - http://wiki.secondlife.com/wiki/Project_Bento_Skeleton_Guide - claims that the tongue and lip bones are parented to the jaw, when in actuality they are parented not to mFaceJaw, but instead to mFaceTeethLower. This bit of information is confusing, but leads me to believe that creating a joint offset for BOTH mFaceJaw as well as mFaceTeethUpper/Lower is what may be creating the strange jaw behavior I am currently seeing. I would very much appreciate some official insight on what is supposed to be going on here. Further edit: By some more experimenting - and having SL display the skeleton for me - it does indeed appear to be the case that SL does not take kindly to trying to offset mFaceTeethUpper and mFaceTeethLower. I will attempt to see whether leaving these at their original location has any sort of positive effect. Final edit & solution: After a solid day worth of research and experimenting, I've come to the following solution: Do NOT, not EVER offset mFaceTeethLower OR mFaceTeethUpper right now. It is perfectly fine to have these bones receive offsets via moving their parent bones, such as mFaceJaw. But do NOT move these bones on their own, it will inevitably lead to very strange issues. As soon as I re-aligned mFaceJaw and mFaceTeethLower to their original positions, then moved ONLY mFaceJaw to its intended location - seeing as mFaceTeethLower is unrigged in my mesh - the problems disappeared. Likewise the upper lip deformation disappeared by moving mFaceTeethUpper back to its original position and its child bones to their intended offset positions. This leads me to believe that there is some bug calculating offsets from mFaceTeethUpper/Lower, which may be connected to the statement in the wiki, falsely stating that the lower lip and tongue bones are parented to mFaceJaw, which they very obviously aren't.
  12. What you might be looking for isn't the mSkull bone, but instead the HEAD collision volume, which what most mesh hair seems to respond to, so as to respond to head size. In that case, I'd suggest raising that volume bone up and rigging some vertices to it so as to make the changes show up when using joint offsets.
  13. The issue has been solved as of a few minutes ago. It appears the blame does lie with the official .fbx files, which appear to have wrong joint rotation data as far as I can gather. I have manually transferred my 3dsmax rig to a blender avastar rig, and it now imports as intended. Thus a plea for LL: Please fix your official source files, many people depend on these being right.
  14. I've been working on a custom mesh avatar using bento facial bones, among others. The head mesh has been rigged using 3dsmax and one of the source .fbx files from the wiki page. It features custom bone offsets, and when uploading, looks perfectly fine in the upload preview window when I enable skin weights and joint offsets. However once worn inworld, the lip bones as well as the tongue base/tip end up in the wrong positions, giving the whole setup a rather smashed-in look. I haven't edited any bone rotations, simply moved the dummy objects into the new, desired positions. If anyone can offer any help on this subject, it'd be much appreciated, since I'm quite at a loss as to what may be wrong. The mesh on the right is my import, the one on the left shows it being worn. As you can see, the eyelid bones, forehead etc, all look correct, but mouth corner, upper and lower lip bones as well as tongue bones are as if their root bone has been rotated in some strange way.
  15. Thanks, I did manage eventually after much reading and cussing Now the last thing to figure out is why the wireframe of my avatar mesh - the one imported from collada - appears very much destroyed, aka full of holes. Only wireframe though, shaded view appears fine. I'll probably just attempt a re-import since now I have a decent idea of how to get things done. Edit: And i managed it. A re-import got rid of the wireframe strangeness. I probably hit some magic buttons whilst experimenting
  16. I have a somewhat related question, since I'm trying to apply some final tweaks to my model. Since most of my workflow happens in max, but I'd like to use avastar's slider features for a bit, is there a way to get a rigged mesh from 3dsmax bound to the avastar skeleton? I can export per-vertex weights as .env in max, possibly more, so can I then transfer said mesh over, then bind it to the skeleton/armature and load the weights back in somehow? Also does this process work back and forth? Edit: After much fussing with how to export, I at least managed to get a collada transfer. So I now have an avastar rig and my own rig in the same file and lined up properly. I wanted to look up retargeting in the blender manual, but while the entry exists, it is empty. Is there anywhere I can read up how to retarget my mesh body to the avastar skeleton, whilst retaining the bone influences? Nother edit: After even more fussing, I finally understood how to keep the mesh & vertex groups, remove the previous armature, and use the bind menu to apply the avastar armature. It appears my mesh has now successfully been bound. My issue should be resolved!
  17. Ooh wonderful. Would retargeting from your female to your male skeleton then be more straightforward? If so, I can probably just wait and get to work on other stages, such as getting some hand poses set up in blender and making the alpha faces for the existing meshes. If I should just follow a different workflow altogether, let me know and I'll be sure to give it a try - and once again thanks, I can't begin to say how much your work is both helping out already and going to help in the future.
  18. Hiya, once again me with a rigging issue. I've been using Polysai's excellent rig to get my female/androgynous bodies rigged, which has, after realizing I have a bone affect limit of 4, yielded some very good results and I have them ready for further processing. However the male body is giving me some trouble. For this one, I am using the latest bento male skeleton file off the wiki page (called something akin to BentoMaleSkeletonWithPosOffsets), and initially remapped my androgynous weights to a male body on polysail's rig. I then took the male body mesh and retargeted it to the male skeleton, which had the joins appear in the right positions as far as I could see. But upon importing into SL, the male mesh bulks up when worn on the male shape, and I'm somewhat clueless where those extra deforms come from. I've successfully done male rigs before, and iirc transfering weights from a female mesh to a male rig and retargeting was a valid process. But if I committed an obvious mistake there, I'd much appreciate being pointed toward it, since I've been at it for a few long hours now and can't find the cause.
  19. I've put some more research into the hand issue I was seeing. Apparently, with your skeleton, I have to rotate R_HAND and L_HAND forward by 10 degrees, then SL will display my hands as they are in 3dsmax. Also a quick question, since I about finished my female rig and am about to begin the male one. Is your skeleton universal in some way so I can rig both easily, or should I rig on a different male skeleton for now, and retarget later on if/when you release a male skeleton speficially? Because iirc they do use different bone lengths in some cases
  20. Definitely looking forward to the changes I have a question regarding the hands, which I didn't see anything mentioned about, apologies if it was answered before. When I did my hand rig, I used LEFT_HAND and RIGHT_HAND as base for the palm, and the finger mBones for the fingers themselves. I am not setting any joint offsets. The rig behaves as expected within 3ds max, though when I import into SL, while the hand scales correctly, the fingers seem to be offset backward from the hand as far as I can see. I can provide screenshots of needed. Also, I am SO glad being able to straight import my .dae files finally rather than having to paste missing bone information. Feels good, man.
  21. Thanks very much for the info. I'm not looking to go /too/ complex yet, probably just preparing finger animations and, once I got my avatar head done, a facial rig for an anthro head. So knowing that I can do simple rotation based keying etc does help a lot. And any scale based anims I'll just have to make at the original size, but I can work around that. Also, I very much appreciate the work you're doing. As someone who does have years of experience making SL content, though virtually none in animation, and little in rigging, this setup and the prospect of having something akin to avastar for max is amazing news for me, along with the possibility of anim export in the future.
  22. Thanks for the pointers. On previous avatars I worked at 10.000% scale on all bones, which was ignored by SL, it just made things a bit awkward. Scaling the root token and resizing for export is a good idea, I wasn't sure if it was a workable solution, but I'm glad to know it is On a final note, once animations can be exported, should I be able to do the same workflow? Aka scale the rig up, animate, then scale it down for export?
  23. I've looked at some of the rig examples, most recently the max 2012 bone rig, which while very nice, has the same problem as all the other rigs I tried to get into max. Its /tiny/. Could someone please help me out by letting me know how I can achieve a bigger working model, so I don't constantly run into the near clip plane hiding parts of the model, while still achieving a proper export? Or is the only way to get a correct export to work on the tiny tiny scale and subsequently export that way? Since whenever I try to upscale the rig, I just end up with a stickman body mesh. Once again, thanks very much in advance.
  24. Once again I ran into some issues I can't quite sort out. Using 3dsmax, I imported the latest skeleton files as per the wiki instructions. I set display units in max to meters, and system units to 1 unit = 1cm. This imported the rigged body mesh at the correct size in max. I then created an avatar mesh and brought that into 3dsmax. I verified that all its transforms were nulled, so its scale was at 100%, no rotation or offsets. I bound the mesh to the skeleton. I then exported the rigged mesh as collada, attempting to use both centimeters and meters as unit conversion. The mesh itself imports fine into SL, and looks the correct size when rezed inworld. However once worn, the mesh becomes an assortment of noodles for limbs, as in, the limbs, body, etc are incredibly stick thin. The problem is, I have no idea why. I thought I followed the guides to a tee, and all the units and transforms look good. Both the bone dummies as well as the mesh itself is at 100% scale, the mesh has no offsets I can see, and the units setup is as described. I know I fixed this problem in the past, I believe by cranking up the bone scale to 10.000%, but I wonder if there isn't another way that actually allows me to have a file for once where scaling isnt entirely broken just to get a legit result? Once again any help is greatly appreciated EDIT: Apparently the problems begin much earlier than that. Trying to import the bento skeleton, I set the system/display units according to the wiki, but no matter what I do, the model ends up absolutely tiny. And it seems that no combination of system/display units changes anything about that. So please, what is the scaling I need to use to /actually/ have a properly scaled skeleton available to me?
  25. Thanks so very much first of all! That was pretty much all the info I needed, I appreciate it a lot. So many good news in all that, it's very reassuring to me that LL is doing these new features right. As for the third question, I mostly build anthro avatars, so I was wondering if I'll be able to have a jaw-joint bone I can use in order to animate the muzzle's jaw. Lip bones will come in handy for expressions to be sure, as will pos/rot animations for bones. Also, good luck on the .anim exporter. As avid max user (and sometimes loather), this will be a huge deal for my workflow, so you get all the kudos from me for tackling this
  • Create New...