Jump to content

Henri Beauchamp

Resident
  • Content Count

    48
  • Joined

  • Last visited

Community Reputation

11 Good

About Henri Beauchamp

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. AFAIK, the Cool VL Viewer is the only viewer to still be able to render ”classic clouds” in SL, for I added local (viewer-side) cloud data generation shortly before LL shut it down on their server (I basically reverse-engineered their cloud data generator, and when the said data is not sent by the server, the viewer uses its own data generator and injects the result in the renderer): the only difference with server-generated data is that every Cool VL Viewer user in the same sim gets a different cloud coverage (since the data is not shared between them all). Also, classic clouds are generated for *all* *rezzed* sims (i.e. if you increase draw distance enough to see them, you will have them rendered in the neighbouring sims as well). You may also change the classic clouds rendering altitude (it defaults to its normal 192m average altitude). Singularity, on its side, is able to render classic clouds when the server sends the corresponding data (i.e. OpenSim non-var-region sims).
  2. Raycasting against rigged meshes *does* occur and is fully implemented in the viewer. It is just not taken into account for touch events, drag and drop, etc... Again, the rationale was probably that since rigged meshes were destined to replace the SL avatar mesh body parts, they were to be considered as the latter and not as a ”normal” attachment...
  3. This is not a bug, but a feature... LL intentionally coded touch (left mouse button click) in the viewer to ignore rigged meshes. This is not because it could not be done (it could !), but my guess (since no comment in their code explains it) is that the rationale behind it was that rigged meshes are supposed to ”replace” the SL body mesh, and the latter is not clickable either ! Allowing to touch your rigged mesh body would, for example, prevent you from stirring your avatar with the mouse (by touching its body an keeping the left mouse button pressed while you move the mouse to stir). You may however right click rigged meshes and choose ”Touch” in the pie menu to get the desired effect... On the condition that you did enable ”Pick rigged mesh” in the Tools menu of the viewer.
  4. I think you misunderstood me: I meant, non-mesh attachments (SL-prim based, and possibly sculpties) and I was not speaking about non-rigged mesh ones... There is simply no possible way for a SL prim based attachment to bear an UV map matching the SL avatar's, so it makes using avatar bakes on them rather (totally, IMHO) pointless. The sculpties case could be advocated, but I personally doubt a sculpty could be designed which resulting mesh would natively map to any of the avatar's UV maps... Also, I see no point in allowing to use avatar bakes on HUDs. I think it's a must-have: think of your armor example, that won't cover hands and neck, but that could use your baked upper avatar texture: you'd need a custom Alpha layer for it and won't want the upper avatar body to be auto-hidden. Plus, it's super easy to implement (simply doubling the pseudo texture UUIDs by adding a set for non-auto-hiding bakes).
  5. The Cool VL Viewer now supports "bake on mesh". On a side note, this feature would be better named "avatar texture bakes on attachments" since it does not bake textures for any given mesh (i.e. meshes with UV coords not matching the SL default avatar won't show right) and allows to display baked avatar textures on any kind of attachments, including non-mesh ones and HUDs: this could possibly be of use for scuplties (if you can manage to build one that would map natively with Av UVs), but I fail to see any practical use for simple prims and HUDs... Questions for the implementers: Will "bake on mesh" apply to "animesh" attachments ? Won't it be better to prevent bake textures on non mesh attachments (for speed optimization purpose and actual usefulness of the feature). Will there be some way to disable auto-hiding of avatar parts (I see a corresponding check box in the texture picker code, but it is currently not active and lacks any code for this kind of support). The idea is that you could wear, say, a rigged mesh calico which mesh won't cover the collar part around the neck neither the arms, and won't want the full upper body to get hidden as a result. Or, think of mesh "boobs" that could also use bake on mesh on SL avatars *if* it was possible *not* to hide the upper body part. As for how to implement it, the simplest way would probably be to affect a different pseudo-texture UUID for bakes without auto-hiding (e.g. IMG_USE_BAKED_UPPER_NO_HIDE in excess of IMG_USE_BAKED_UPPER).
  6. Whirly Fizzle wrote: Ok JIRA issue filed for the broken werewolf avatar. BUG-40672 - [bENTO] Werewolf avatar is deformed on Bento viewers only Glad you could repro the issue.
  7. Gaia Clary wrote: Since Bento it is possible to only import partial skeletons. Especially you can decide to only export the weighted bones of your character (because unweighted bones are not used for deforming your mesh). So, when you import this horse with the Bento Viewer, then the mChest bone is not imported. But... During importing your character all "missing" bones are taken from the original skeleton. (the SL Importer has no way to find out where the mChest bone has meant to be placed)This is results in a skeleton where no joint position is defined for the mChest: .../... I am not sure if i translated chinese to japonese or if i was more succesfull this time. But i hope it helped a bit. Many thanks for your (heroic !) effort, but the case you are exposing is not corresponding to the issue: the mesh in question was uploaded by his creator long ago (before Bento even existed); it is *not* using any of the Bento bones/animation features, and renders just fine in non-Bento viewers. The compatibility problem is with the Bento viewer code itself, obviously.
  8. Teager wrote: It's likely that this avatar rigged its face to either attachment bones, volume bones, or both, since I know this is a technique Dreamcrawler has used for other avatars. I've seen plenty of avatars with both attachment rigging and volume rigging that all seem to be fixed after the bug fix implemented for the jira Whirly linked on the previous page. If your bento viewer is ~2 months outdated, you would be seeing deforms like the ones you linked. The other option could be the deform animation in the avatar simply failing to play, perhaps for being on a sim with scripts disabled, or some similar problem. I'm following closely (checking the git daily) all the changes to LL's bento-box RC viewer, and none of the changes that went into it fixed that issue. Plus, I also tested the latest RC bento viewer binary (v5.0.0.320160) and got the exact same results with it. As for the anim failing to play, no, it's not the issue at hand either (I've seen this in different sims, and none had the scripts disabled).
  9. Gaia Clary wrote: There have been a few changes in the Bento Skeleton over the past few months. If the broken character happens to be based on an outdated Skeleton definition, then this most probably explains the deformations. That mesh is not based on a Bento skeleton, but on the SL avatar v1.0 one, so the changes in question are unrelated, as long as the Bento skeleton is kept compatible with the avatar v1.0 skeleton... Also: if a mesh is weighted to a bone that has a joint offset defined, then the exported skeleton must also contain all parent bones in the bone chain which have joint positions defined. This must be done regardless whether the affected bones are used in the mesh or not. This is all Chinese to me ! :smileylol:
  10. Medhue Simoni wrote: How is it animated? What bones are they using? Did they use supported ways to do this? No offense to the creator, but if they just used some unsupported way to animate with, I'm not so sure LL should be fixing it. This is the risk a creator takes by using unsupported ways. This is exactly why I never ventured into the unsupported ways. Totally sucks for people who bought it, but the creator will likely want to redo the avatar rig anyways. The avatar will end up being many times better. No idea how it is animated (you'll have to ask the creator). And don't count on me to enter an argument about what is "good practice" and "bad practice" when it comes to mesh creation (my knowledge in this field is close to zero). However, as a programmer (and an old, experienced one, at that), I always strieved to provide compatibility between existing "contents"/assets/data/whatever used by one of my programs and newer versions of that program, and so LL (mostly) did so far. Also, the creators have been using so far what the programs allowed them to do, and both the SL viewers and servers have been pretty lax, from the very start, with the meshes format/constraints, with very few (if at all) guidelines as to what was "legal" or not; so you can't blame now the said creators to have used all the possibilities that were offered to them... At the minimum, LL's should investigate that issue and check whether it would break a lot of contents or not.
  11. Whirly Fizzle wrote: Hmm there isn't a JIRA issue for that, unless it's a case of https://jira.secondlife.com/browse/BUG-37634 That bug is supposed to be fixed though. That bug seems to affect other bones than just the face bones, which is not the case here... Probably a different bug, entirely. Oh, and resetting the skeletton doesn't fix the issue either (it's an animation issue, and no, reloading the animations for the affected avatar is not either a work around for it).
  12. Yep, it's that avatar. The creator IMed me back saying he and LL were aware of this issue: apparently a problem with how the face bones are animated and how Bento ruins it... He also said a lot more mesh avatars by various creators were affected. However I so far only noticed this issue (several times over the past couple of months) on this specific mesh avatar, and since I saw no related fix in the Bento code repository for it, I started to grow worried it would go unnoticed..
  13. Not sure if the issue has already been reported (I don't have the time to browse and read the whole thread, sorry), but here is a rendering problem I encounter with Bento viewers (both LL's and mine): http://sldev.free.fr/pictures/Distorted%20DC_NG-WW_%28Medium%29_Body-2_001.png The snapshot was taken with the Cool VL Viewer v1.26.19 (Bento-enabled, experimental branch), but I get exactly the same result with LL's latest Bento RC binaries. I made the creator of the affected mesh aware via an IM yesterday, so he may contact you as well about it.
  14. Now, I'm pissed off ! If only people could stop spreading FUD !!! The reasons why I prefer keeping a few (very personal) pieces of info (such as my phone number, which I reserve to the exclusive usage of my family and friends: it's on "liste rouge" and is never listed in any public record/phone book) over seeing my viewer listed in the TPV directory are mine, and they are also totally legally founded (mind you, French (and EU) laws are more protective than US laws about privacy, and we do care a lot about privacy in "old Europe", and find US companies aggressiveness towards private data theft of foreign citizens quite disturbing and even revolting !). For your info, my identity is also known to LL (since money exchanges have been done between LL and me). I just don't want to give away info that is excessive for the purpose (here, the purpose is a "contribution agreement", something that should really not require me to give out a red-listed phone number, especially since I won't understand a damned word of spoken English !). This said, and citing the paragraph 6 of LL's TPV policy: "6. The Viewer Directory and Self-Certification We created the Viewer Directory to help promote awareness of Third-Party Viewers within the Second Life community. Unlike the other sections of this Policy, participation in the Viewer Directory is currently not a requirement for connecting to Second Life. " and at the end of that paragraph, you can read: "c. The Viewer Directory is a self-certification program. Linden Lab does not represent or warrant any independent testing or verification of compliance of any application listed in the Viewer Directory. We disclaim all liability associated with applications in the Viewer Directory." Emphasis mine (since some of you just can't seem to be capable of reading and spotting the phrases that actually matter). TPV viewers are Open Source and the beauty of Open Source is that you can check by yourself that a software is not malicious or violates any rule. In the case of the Cool VL Viewer (and its former Cool SL Viewer incarnation), the TPV Policy compliance is 100%. It's even better than most other TPVs, if not all: do you know, for example, of any other TPV which presents you with the required disclosures on first run (para 1.c of the TPV Policy) ?... Well, that feature has been implemented in my viewer only one week (!) after LL published that policy... I'll also add that my viewer has been around since 2007: it's the oldest actively maintained TPV. If, at any point, LL had detected any non-compliance to their TPV Policy, do you really think they won't have blocked it already ? Finally, I've seen stupid things posted in this thread about the Cool VL Viewer features: my viewer got weekly releases and features that stay top-notch and in sync with LL's viewers, including projects viewers: the experimental branch of my viewer implements Bento, for example. Yes, it's a v1 UI viewer (the UI is based on (but also vastly expanded from) LL's v1.18 viewer), but it got all the bells and whistles of modern viewers. Now, as for the "popularity" of my viewer, I really do not care ! I made it for myself and I'm only sharing it as a service to like-minded people. If you don't like it, then fine, please use any viewer fancying you !
  15. The new Bento project viewer (v5.0.0.313150) emits the following warnings about the new shape visual parameters: 2016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 12016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 22016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 42016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 102016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 112016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 142016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 152016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 182016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 202016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 242016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 252016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 272016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 352016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 1552016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 1852016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 5052016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 5062016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 5172016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 6292016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 6502016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 6532016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 6562016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 6592016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 6632016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 6652016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 7582016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 7642016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 7652016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 7962016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 7992016-03-31T07:32:03Z WARNING: createVisualParams: could not link driven params for wearable Henri's shape id: 1105 Note that the warning about visual param 1105 (a physics param, so it's not quite as important as the rest) exists in all viewers, but all the others are new, and do impact the newly introduced "sliders" parameters...
×
×
  • Create New...