Jump to content

Henri Beauchamp

Resident
  • Posts

    181
  • Joined

  • Last visited

Everything posted by Henri Beauchamp

  1. :just smirks... Note the ”:” instead of ”/me ” (i.e. easier/faster MU*-like emoting), which was my very first patch to the Linden code base, back in the ”Cool SL Viewer” days... The whole spirit of my viewer is behind this very first patch (that every TPV adopted since): faster, easier, lighter... and still full-featured. 😜
  2. This already happened with the Cool VL Viewer v1.27.0 (just like I more or less announced in this forum months ago), and yes, Extended/Enhanced Environment rendering will stay totally optional in the Cool VL Viewer future releases. I am currently working on making the EE renderer compatible with Windlight settings (the other way around, i.e. using (a subset of) EE settings with the Windlight renderer, already worked for months in the Cool VL Viewer). Once this will be done, v1.27.0 (experimental branch) will be promoted as v1.28.0 (stable branch).
  3. This got nothing to do with multi-monitor support (neither with threading, as mentioned in replies), but with how the viewer UI is implemented. Indeed, the first time I launched a SL viewer (back in 2006), I have been extremely surprised to see that the UI (menus, floaters, panels, etc) was all rendered in OpenGL, which is a rather costly way of dealing with an UI, when GTK+, Qt (for Linux) or native OS UI elements (for Windows and macOS) could be used instead (at zero cost in term of frame rate)... Back at that time, the CPUs were mono-core ones (with barely a quarter of the power of one of today's CPUs single core), the GPUs were 1000 times slower/less powerful than today's GPUs and the OpenGL UI consequently did represent quite a significant fraction of a 3D frame rendering time. While that choice (rendering everything in OpenGL, UI included) could be seen as very disputable back in that time (mainly because of performance concerns), it did yet bring a number of advantages: It is fully cross-platform, providing the user with an uniform experience in all three OSes the viewer could be run under. It is easier to maintain for viewer developers (no need to deal with each OS UI peculiarities, or even with several UI toolkits for the same OS such as GTK+ and Qt under Linux). It allows for a tighter bind between the viewer code and the UI (easier to keep UI elements in sync with what happens in-world). It inherently provides a non-blocking UI (since the UI is refreshed in the main loop, not blocking the latter waiting for the reply of an external UI toolkit itself dependent on the user actions), and this without the need to use threads. It also must be noted that it is how most games are coded anyway... One of the drawbacks (beside the frame rate performance impact) is that you cannot drag an UI element out of the 3D rendering window. It is doable (it would require heavily modifying the llui viewer library to use a toolkit such as Qt or wxGTK), but not an easy task either and would be quite time consuming...
  4. You can try the Cool VL Viewer v1.27.0 (experimental version/branch), which implements a dual renderer (Windlight and EE, switchable on the flight), beyond also providing EE settings to Windlight real-time translation (which also works and has been working for months in the v1.26 stable version), when using the Windlight renderer...
  5. Make sure your mesh body is set for alpha blending or alpha masking, else Alpha won't work with baked textures on mesh.
  6. Yes, I already spotted this, but convertToLegacy() calls convertAtmosphericsToLegacy() and there, is a comment saying: And the whole conversion depends on the actual presence of SETTING_LEGACY_HAZE key in the EEP settings LLSD... Should I conclude that this key is indeed (and will stay, in the future) present in the EEP settings ? It should not be hard to add configurable textures for Windlight's Moon, Clouds and Sun... The independent Moon position would just be a missing feature.
  7. The idea is precisely to implement the same conversion algorithm into viewers capable of dealing with EEP settings (at both the inventory/asset and LLEnvironment levels) but that won't adopt the EEP renderer (instead keeping Windlight's renderer). The Cool VL Viewer v1.26.23 (i.e. the experimental branch) is one such viewer (you can even edit the EEP settings in it, apply them to the region, etc, but of course, you cannot see EEP settings applied locally rendered as their equivalent Windlight ones). I could code such a feature myself, but why reinventing the wheel ?... As I explained in a previous post, I am for now undecided about what I will do regarding EEP (and more precisely its renderer): I could adopt it (if it improves enough to avoid loosing FPS when compared to the old Windlight renderer), or implement Windlight rendering of EEP settings (via this conversion algorithm, for non-region/parcel settings)...
  8. Would LL be so kind as to publish the relevant code, so that it could be integrated without having to reinvent the wheel into viewers that keep the Windlight renderer (this way, the viewers that support EEP settings but don't use the EEP renderer could render Windlight settings corresponding to EEP ones, even when the EEP settings do not come from the region itself) ?
  9. This is not how things work: for a start, your ”flag” cannot be transmitted together with the avatar bakes. The new UUID set will be ”transparent” to the final users: it's the code behind the UI of the texture picker that will take care to pick the ”*_NO_HIDE” version of the UUID constants when the ”Auto hide body part” check box is un-checked. It will also be fully backward compatible with the current BoM implementation. Frankly, this is so trivial (it can be implemented and fully tested in a mere couple of hours, at the very worst), that it would be a shame to wait months and an hypothetical ”follow-on project” to have it... I bet you will see more and more reports about ”BoM is broken because I can't have my feet/hands/head/whatever shown while using a bake texture on the rest of the mesh body part”... As for the JIRA, I gave up using it, sorry. It does not even remember the login credentials over sessions (even with the ”Remember login” check box checked), and most things I reported on it over the many years I contributed to the SL viewer development and debugging got mostly ignored... This is without mentioning that (long time: 12 years already) viewer developers such as myself cannot even see or contribute to most of the JIRA issues (apart from the BUG ones, provided you are the initiator)... :-/
  10. Yes, this is typically a case that would be fixed by my suggested NO_HIDE set of bake UUIDs...
  11. I can speak only for myself and the Cool VL Viewer, but while I already backported the environment settings editing/importing/creating stuff (UI (fully reworked), inventory, etc) in the experimental branch of my viewer (v1.26.23), I for now refrained from backporting the rendering part. Why ? Because it is obviously a moving target with lots of breakages still to be repaired, and with abyssal performances. At this point, I am not even sure I will actually adopt EEP rendering for my viewer, the reasons being: This is not something I need. To tell you the truth, I don't even use ALM (it looks too blurry and gloomy for my taste) and I keep my viewer locked in ”midday” with default Windlight settings (because well, I don't care much about the photo-realistic aspect of SL: for me SL is just a platform to role-play, and imagination is the key factor in RPs, not things that would be imposed on me such as the day length, that obviously cannot follow/match the variable rhythm of a RP). If it means that I must give-up performances for a feature I never asked for and that I cannot disable to regain the original performances, then screw it ! For now, I am considering three options: Not implementing EEP rendering at all, but making it so that EEP settings are ”translated” and rendered as their Windlight counterparts. Keeping the Windlight renderer and implementing the EEP one along it, allowing to switch back and forth between them (thus letting the final user the choice between ”prettiness” and performances). Waiting (weeks, months, who knows ?) after EEP makes it to LL's viewer and see what happens (will performances increase over time to match the Windlight renderer's ?). Now, I think that things could be improved a lot, performances-wise, if you could consider the following suggestions of mine: Do we really need to recalculate the environment parameters at *every frame* ?... 5 updates a second sounds like more than sufficient to me (this could even be made user-configurable, because to tell you the truth, one update per minute would be acceptable for my use of SL), and cached parameters could be used for all the other frames in between two updates. Won't it be smarter to delegate environment calculations to a separate thread ?... Once the above caching implemented, it would be trivial to sync the results once per frame between the environment calculation thread and the viewer rendering (and main) thread. With today's multi/many cores CPU, we do need to use more threads !!! These were my two cents about EEP...
  12. PsiCorp Core v2 avatars can also be setup to use BoM textures and work great with them. Core Nova can too, but alas its UV maps are not so great (especially on the back side: the buttocks UV map is totally off SL's avatar, and there are also issues around the neck and shoulders).
  13. @Vir Linden There is a feature I already wrote about on this forum (it was last year, in the initial thread about BoM), that I still think would be useful: have an additional set of bake UUIDs that won't trigger the auto-hiding of the corresponding parts of the avatar. I encountered no later than yesterday a use case for such bakes: a mesh body avatar (that lets you use the SL avatar head) with a half-neck mesh part, that allows a smooth blending of the mesh and SL avatar head/neck: when applying the baked head texture to the neck (so that the neck part of the mesh is colored like your SL avatar neck), the head vanishes... You can't use a bake on the neck, meaning that particular mesh body cannot blend properly at the neck level... Other use cases would be mesh bodies with parts of the underlying avatar showing (think cyborg, amputated avatars, etc): for those you don't want the full upper or lower body to vanish when using baked textures on the mesh parts, but instead would use appropriate Alpha layer(s)... The implementation would be trivial, as I see it; in the texture picker, add a ”auto-hide body part” check box (and IIRC that check box existed in the initial BoM implementation, but was not ”wired” to any code in the viewer), and when not checked, instead of applying, say, ”IMG_USE_BAKE_HEAD”, the texture picker would apply a new ”IMG_USE_BAKE_HEAD_NO_HIDE” UUID to the edited face. Then, in the viewer code, skip the body part auto-hiding when any of the ”*_NO_HIDE” bake textures are used instead of their counterparts.
  14. The Cool VL Viewer already supports bake on mesh (and has been supporting it for over a year already), and the current sources for the viewer can as well be compiled with the new Universal tattoo layer support. The next release (to be published on next Saturday) will have the universal layer support compiled in.
  15. 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).
  16. 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...
  17. 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.
  18. 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).
  19. 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).
  20. 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.
  21. 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.
  22. 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).
  23. 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:
  24. 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.
  25. 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).
×
×
  • Create New...