Opaque Entities

taleden

Does the 'opaque' light flag correctly handle light generated from switchable texture lights? I have some big double doors which are flagged 'opaque' and start in the closed position (for light calculation), however when a light is switched on or off on one side of the doors, the effect can be seen on the other side as well. Any ideas?

Cagey

From my understanding of the code, I think that switchable texture lights are lumped together with everything else by CreateDirectLights before the BuildFaceLights step uses CalcPoints to find the relationships between different light patches...

I had some problems getting opaque faces to work correctly yesterday with a simple direct light--I'm wondering now if the code is working 100%. I'll be testng the standard 1.7 HLRAD against 1.7p9 today to see if there's any difference.

taleden

Alright.. if you find it might help, I can send you the room I'm working on again so you can see the effect. I've also noticed that, as far as I can tell, light generated from a skybox (according to light_environment) is not blocked by opaque entities either - there is a skybox above my opaque double doors, and in the room underneath there is a big bright white circle of light coming from the skybox, even though the skybox should be behind two layers of opaque entities during light calculation. I tried using multiple light_environments with the -noskyfix, however I wasn't able to get it to treat them independantly (possibly because there is another skybox nearby which I do want to generate light - the two light_environments might be too close to have it handle them differently).

Cagey

<!--QuoteBegin--taleden+May 4 2003, 11:40 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (taleden @ May 4 2003, 11:40 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Alright.. if you find it might help, I can send you the room I'm working on again so you can see the effect.  I've also noticed that, as far as I can tell, light generated from a skybox (according to light_environment) is not blocked by opaque entities either - there is a skybox above my opaque double doors, and in the room underneath there is a big bright white circle of light coming from the skybox, even though the skybox should be behind two layers of opaque entities during light calculation.  I tried using multiple light_environments with the -noskyfix, however I wasn't able to get it to treat them independantly (possibly because there is another skybox nearby which I do want to generate light - the two light_environments might be too close to have it handle them differently).<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Sure, toss the test case it my way <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->

wrongwaygoback

I have had huge problems using the opaque switch on my map. I chucked it on a couple of roof pipes, and from then on ZERO light could enter the area under those pipes. To test this I put a light vertically aligned to the pipes but in the middle of the room. On one side of the room the lighting was fine, on the other side, pitch black.

Also, when I used the flag compile time was doubled. Once removed, everything was hunky-dory again, but as I generally do my lighting at the end of room creation, it took me a couple of hours to find the problem.

I could do a screen shot tonight, if you don't get what I'm saying.

taleden

I do get what you're saying, and actually I think what you're experiencing sounds more like the lighting bug that was just fixed in the latest tool release - 1.7p9. Try compiling with p9 (or with the -oldmath switch in p8) and see if you get the same effect.

My problem isn't that opaque entities are too opaque and somehow suck up light from the rest of the room - my problem is that they're not opaque enough, and light (especially switchable lights) is penetrating through them where it shouldn't.

wrongwaygoback

<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->was just fixed in the latest tool release - 1.7p9. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->

Jeez, 1.7p9? I need to bind "w" "download XP-Cagey tools". Is there an update each day at the moment?

taleden

Just check for new posts in the 'reduce max-planes...' thread - its stickied on this forum. Cagey updates the first post with news whenever there's a new release. There hasn't been one for a little while - the last major release was p7, which had RAD algorithm optimizations, but then the lighting bug I mentioned showed up so he added the '-oldmath' switch and released p8 right away; now the lighting bug has (hopefully) been solved, so p9 was released a few days ago with fixed algorithms.

bind "w" "dlcageytools"

Cagey

<!--QuoteBegin--wrongwaygoback+May 4 2003, 04:20 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (wrongwaygoback @ May 4 2003, 04:20 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--><!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->was just fixed in the latest tool release - 1.7p9. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->

Jeez, 1.7p9? I need to bind "w" "download XP-Cagey tools". Is there an update each day at the moment?<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Yeah, I know there have been a lot of quickie bugfix releases -- I need an early adopter program with a last "stable" release for download. It's difficult to talk about "stable" releases, however, when the code base that you're basing the modifications on is a moving target with some documented bugs.

The last two releases were 10 days apart... I'm assuming people would rather have the bugs stamped out sooner vs. later. If I were using the valve versioning system, I think I'd have laid it out this way:

1.7p - 1.7.1.0 (feature addition)
1.7p2 - 1.7.1.1 (bugfix)
1.7p3 - 1.8.0.0 (major feature addition)
1.7p4 - 1.8.0.1 (bugfix)
1.7p5 - 1.8.1.0 (feature additions)
1.7p6 - 1.8.1.1 (bugfix)
1.7p7 - 1.8.1.2 (bugfix)
1.7p8 - 1.8.1.3 (workaround)
1.7p9 - 1.8.2.0 (feature addition / bugfix)

I chose to use the patch # notation instead so that Merl could safely continue using a numbering scheme without anybody getting confused. It's bad enough that 1.7 is an offshoot and later version of 2.5.3 without having to worry about a third set of numbers.

There have been nine releases in 3 months, which is more than you'd see in a professional environment, but as I've said I'm being less rigorous than I would with something I expected people to pay for (I'm not being purposely cavalier or careless, but I'm not doing formal unit testing, either... if it works with the test maps, I release it).

I've been working for the last few week on setting up an actual home for the modified tools, but it's not ready for prime time yet. I'm thinking about using a notification list eventually, but for the time being the thread here is a quick way to see if there's been an update.

If/when I perform a fundamental rewrite the compile process (there's a lot of room for improvement that tweaks can't implement), an optional check for updates probably wouldn't be too hard to include in the program(s).