Jump to content

Henri Beauchamp

Resident
  • Content Count

    60
  • Joined

  • Last visited

Community Reputation

30 Excellent

1 Follower

About Henri Beauchamp

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. Make sure your mesh body is set for alpha blending or alpha masking, else Alpha won't work with baked textures on mesh.
  2. 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.
  3. 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)...
  4. 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) ?
  5. 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)... :-/
  6. Yes, this is typically a case that would be fixed by my suggested NO_HIDE set of bake UUIDs...
  7. 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...
  8. 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).
  9. @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.
  10. 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.
  11. 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).
  12. 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...
  13. 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.
  14. 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).
  15. 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).
×
×
  • Create New...