Deleted1205226User Posted April 12, 2016 Share Posted April 12, 2016 As far I understand, Alpha is controlled in both the alpha map and the alpha material property. The flags combine different settings (detailed like mindboggled mention). The most common flags found are:237 - Default4333 - in some glass settings4844 & 4845 - one can solve sometimes problem encountered with the other (flickering, lighting oddities, vanishing transparent mesh) Hope it helps here! Link to comment Share on other sites More sharing options...
Athelbras Posted April 16, 2016 Author Share Posted April 16, 2016 (edited) An update ... The issue does not appear to arise from, or be affected by, rescaling objects from 1:1 via scripting. And it occurs for some vanilla models, but not for others. Unfortunately, I do not have the knowledge to understand individual model Lighting / Alpha properties, much less tinker with them. However, I was able to [knock on wood] get my original Whirly and Rocket Whirly to work correctly without resorting to NVSE, but various workarounds were required. The one continuing casualty is Jokerine's model for Playground UFO (aka UFOHang.nif from the original download) - absolutely nothing fixes the disappearances, not even NVSE's Update3D. And it is not the result of reworking the vanilla model (ufofort01.nif) - that exhibits the same problem. Edited April 16, 2016 by Athelbras Link to comment Share on other sites More sharing options...
Athelbras Posted April 20, 2016 Author Share Posted April 20, 2016 (edited) The invisibility issue strikes again ... I was hoping to use the Mother Ship model in one of my "Whirly" variations, but it too exhibits the problem. Nothing restores it to visibility, other than leaving the area of invisibility, which can be quite extensive. Hopefully, at some future date, a knowledgeable modeler with insights into model Lighting and Alpha Properties will investigate and discover which specific settings a model must have, and not have, to remain visible at all times, everywhere. Edited April 20, 2016 by Athelbras Link to comment Share on other sites More sharing options...
Athelbras Posted April 20, 2016 Author Share Posted April 20, 2016 I am willing to provide a simple test case .esp, with appropriate saved game(s), for anyone who might be interested in pursuing the issue. Link to comment Share on other sites More sharing options...
Athelbras Posted April 21, 2016 Author Share Posted April 21, 2016 (edited) Summarized Update: The results of further investigation tentatively indicates that the presence of various interior cell illuminations, and the lighting / alpha of an object, was merely coincidental. The root cause is now conjectured to be the use and/or misuse of Room Markers, and the effect they have upon objects as the objects transition into and out of those bounded areas. Detailed Update: Looks like cell "lighting" was merely a coincidence with regard to areas of object visibility and invisibility ... The Helios One entry way (HELIOSOnePlan interior), plus initial sections of its two adjacent corridors, are within the bounds of a Room Marker (highlighted via a blue-boxed zone in the GECK's rendering window). While within the bounds of that room marker, objects remain visible. When objects are moved beyond the bounds of that room marker (to be outside of the blue box), they become invisible. Extending the boundaries of that Room Marker enables objects to remain visible in places where they previously vanished - and they continue to remain visible as long as they are within the confines of that extended Room Marker. Similarly, removal of the Room Marker enables objects to be visible everywhere, but it is likely that there are other things dependent on its presence. In general, there is potentially an adverse effect if objects transition across Room Marker boundaries, whether into another such Room Marker or into/out-of an unmarked area. - * - The implication is that various interior cell locations would need to be suitably revised in order to resolve this vanishing object issue overall; i.e. changes which appear to be far beyond the scope of my own mod. It is unclear as to why some objects (including "vanilla" objects) are affected and others are not. [ Thanks are extended to Roy for assistance in gaining this insight ] Edited April 21, 2016 by Athelbras Link to comment Share on other sites More sharing options...
RoyBatterian Posted April 21, 2016 Share Posted April 21, 2016 To further explain the issue; Obsidian didn't understand completely how to make room bounds and portals work properly. The information on linking room bounds is not in the GECK wiki, they can in fact also be multibounds and linked together via the link button to create complex shapes. You have to be careful with it though because there is no way to *unlink* them in GECK. You have to use xEdit in order to do that. That being said, what they did is used them for occlusion but the portals are not dual linked between two room bounds as they should be. They are linked to only one room bound as there is only one present. This created the bug which Athelbras is experiencing and I've seen it myself, but not too often. I have explained this bug to someone else, and I believe they are working on fixing these bugs in cells that need them. Notable ones are Helios and Vault 21 that I have personally seen. Hopefully it will get added to YUP at some point. Link to comment Share on other sites More sharing options...
Athelbras Posted April 21, 2016 Author Share Posted April 21, 2016 Other areas that manifest the problem, and which I used for testing, are Vault 3 and the REPCONN Facility at the REPCONN Test Site. Link to comment Share on other sites More sharing options...
Recommended Posts