Jump to content

OptimoMaximo

Resident
  • Content Count

    749
  • Joined

  • Last visited

  • Days Won

    3

OptimoMaximo last won the day on February 15

OptimoMaximo had the most liked content!

Community Reputation

711 Excellent

8 Followers

About OptimoMaximo

  • Rank
    Maya MahaDeva

Recent Profile Visitors

1,034 profile views
  1. That's called IP theft, as those models belong to The Sims' franchise.
  2. The Belleza original models were made in Maya, which fully supports bind poses. However the creator might not know that Blender, natively, doesn't. The problem that the OP is facing is that their pants were modeled with spread legs, so the issue may persist.
  3. Leaving aside the missing surface in SL, which is most likely a problem with too many materials... In Blender you can't have a custom bind pose (i don't know if 2.8 will bring news about this, in the future), you must rig it in TPose. If you think about it, what you get in SL is exactly what you rigged: imagine the pants like you modeled, just rigged to the normal TPose straight legs... once you import it and wear those pants, the offset would carry over and you get that result you're showing from SL. To use a custom bind pose, you should use Avastar add on, but i don't know whether this feature is still there nor if it works as it should.
  4. Yes, as they are called by the script in two separate sequential llStartAnimation, it is perceived by the user as a single animation. Howerver animations are client side, only the asset server is aware of animations files being sent to the client, the simulator itself doesn't even know that animations exist.
  5. There is an issue with script calls when pairing a bento animation and a body animation for which the bento joints do not start playing. If, for example, you want "cool stand" animation (non bento, body only) to play back and fire "cool hands for stand" (bento animation, fingers only) is not going to work in ZHAO II even when using the method "first animation , second animation" Not entirely true, ZHAO II is set up to take advantage of layered animations as seen in the default walk, where the upper body is driven by a priority 2 animation that differs between male and female and a priority 3 animation that runs on the lower body on both genders, as described here http://wiki.secondlife.com/wiki/Internal_Animations walk 6ed24bd8-91aa-4b12-ccc7-c97c857ab4e0 avatar_walk.bvh 3 & 0 Yes[1] Automatically replaced by female_walk if female shape is worn (priority 3 for pelvis and legs, 0 for everything else) As usual LL's documentation is not accurate, but if you use the developer tools in the viewer you can see that there are two animations playing back when walking (with no AO attached), and switching gender replaces the animation that is playing on the upper body. This is an issue that was brought up at the Bento Project meeting and Vir Linden is perfectly aware of this, but, as usual, nothing has been done about it (it is easier to drop the ball in the creators' hands with a "you can script a work around to make it work")
  6. It all depends from the worn shape. This is something that most can-t see as it-s not exposed in the user face, but the shape sliders system is based upon joint scaling to achieve a bone length. So, since the difference between a default male and female shape sits in their joint scales, the first thing that happens is an accumulation error of the final joint in a chain in world space due to its parents' relative distance: the hand location in world space won't be the same between two different shapes even if forearm, upper arm and collar bone are rotated by the same amount. There is no such a thing as unisex or "fit everyone" animations/poses.
  7. I didn't forget that reason, but this isn't a field where one can claim to have the meal served. I understood that too, Bitsy. I can see the value in that as well, but that's a job that deserves compensation, nobody would do it for free. Failing is easy when the counterpart doesn't want to listen and apply the explained knowledge, just keeping their way and grabbing only the bits needed to make it work anyway. You did what you could, Rey. Being receptive to something is up to the listener.
  8. Why not making a list arranged by material? Ground: Grass Tree/tree stumps Rocks vegetation rubble (leaves, wood splinters, twigs) Dirt Mud Mushrooms Plants Water: River Creek Waterfall Puddles Animals: Mammals Insects Reptilians (turtles/snakes) Anfibians (frogs/toads) Environment: Weather Sounds Animal Droppings Burrows/Hives Fog/Myst Caves ManMade: Campfires Garbage Dead animals (these could be dead for natural reasons but the main reason so far is humans, usually) Furnitures Ruins
  9. The forum is full of best practices, but, as I see it, those are neglected for various reasons: assumes learning more about the 3D tool at hand It slows down the process (less releases in the same time frame) who wants to listen, claims "step by step" instructions on specific topics (like copycats) instead of trying to understand and adapt the principles/methods to their specific case, so they drop out because of points 1 and 2 "I'm a pro already, I don't need your 90's game stuff to dumb down my gorgeous products" who cares (which looks like it is the most prominent reason)
  10. Did you check whether MD import windows has a checkbox to import skinned meshes? If there is and it is unchecked, the skin data would be stripped off the model
  11. From the looks of things in your screenshot, that is an Avastar rig. I'm quite confident that the bones you can't bend are the blue ones, because they're constrained to (invisible) green ones. The blue bones are those you should weight bones influences to, while the green ones are supposed to handle animation only and shouldn't be in the vertex groups list at all. Moreover, you're using collision volume bones there, to get a fitted mesh result (red bones). Those bones are being handled by the Avastar add-on scripts, as Blender can't manage bind poses, natively. This is indeed what squeezes your mesh inside your avatar once imported. Solution 1: purchase Avastar and use its tools and exporter to get rid of the collision volume bones problem and keep going with your learning Solution 2: remove the collision volume and the animation bones, rig only to the blue bones. Make sure to orient the character facing the +X direction and apply rotation on both mesh and skeleton before exporting
  12. I've just upgraded to ZBrush 2019 and i still have to look at the new ZRemesher, by the looks of things it's a significant change since there's a "Legacy 2018" button next to it. So far i can just tell about what I've tried (2018 and older), and the ZRemesher Guides do their job up to some extent. Edgeloop Masked borders and slice brushes to make polygroups splits work nicely but it requires full loops everywhere, ideally perfectly straight. Even using the 3 tools in conjunction, so far, has led to a few spirals in my experience. Sure thing the result is NOT meant to be used as a retopo model, rather it's a mean to convert a Dynamesh into a workable mesh with topology and start the subdivision sculpting for the tiny details (after projecting the subdivided mesh onto the original Dynamesh to catch details that may have gone lost in the process). Might be worth using bits and pieces of it in the retopology though, with the due clean up of the troublesome areas. That's what happens in real game and movie productions too. Don't think that SL is a special case of and in any form. The platform has a few limitations in place for various reasons, but i see a common misconception for which there is a huge difference gap in making models for SL or for another engine, aside from the tech limitations. For one, the idea that bento rigging is any different from the legacy skeleton rigging, or that fitmesh is any different from regular rigged meshes. Again, aside from tech specs that may differ because of the platform implementation of feature that require a different amount of data to handle, there is no difference between the two things (bento vs legacy skeleton / rigged vs fitted) and model making techniques do not differ, unless we look at polycounts (whereother engines can go way higher than SL if needed) I'll give you here a bit of workflow expertise on how this is supposed to be handled: freeform sculpting with dynamesh, up to general shape is achieved and the low frequency details are in place. Polish it to remove bumps. increase dynamesh resolution for mid-fine details sculpting, when done... duplicate the tool and ZRemesh one of the copies, subdivide it an project it onto the Dynamesh left over from the duplication (this catches the details lost in the process) finalize your sculpting on the ZRemesh result with all the high frequency details Duplicate the sculpted Zremesh mesh and bring one copy back to initial subdivision. This way you keep the low-res displacement from the sculpting and you can reuse this to "steal" good topology body parts Duplicate the finalized sculpted ZRemesh and apply all the subdivisions to get a real high density mesh run the Decimation master on this, the decimated mesh is the one to export as retopology base (it keeps shape, details and doesn't choke your app when importing it into Maya, Blender, etc) export the unsubdivided Zremesh result from step 4 import both meshes to your 3D app and check the ZRemesher result topology to identify issues, delete what doesn't work and keep the rest work the empty spaces left over from step 8 bake maps from the decimated mesh OR send the retopoed model back to ZBrush and perform the baking in there, remember to flip Y when exporting the texture. Decimation Master's result is not intended for sculpting or animation at all, that's why you get wonky results by doing so.
  13. Most folks in SL see this as an unnecessary hassle for the perfect 3D mesh sale, IMO. Some time ago there was someone here on the forums claiming that the SL limits on vertex counts are ridiculous, because he had to spend so much time in ZBrush (!) finetuning the ZRemesher to output something that would be accepted by the uploader. Leaving aside the lack of understanding about these ZBrush tools and what they're intended for within the workflow, the average SL user thinks that highpoly = high quality, for which every modeled bit of detail they're able to keep on the mesh counts towards a "higher quality product", and retopology is seen as a "dumbing down my hard work"... totally neglecting details like ZRemesher's tendency to create spiral edgeloops (!!), then wondering why their rigged content deforms weird in some areas or why it takes that long to snap into place before it starts animating along with the avatar animation XD So yes, I do love the retopology process and work, and the satisfaction it gives me when the end result deforms, moves and fits flawlessly.
×
×
  • Create New...