Jump to content

Psistorm Voxel

Resident
  • Posts

    134
  • Joined

  • Last visited

Reputation

4 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  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
×
×
  • Create New...