|
2006-02-10 03:13
|
Picture 1.png (207,590 bytes) |
|
|
Can you attach one of the IBX files for the fighter as well ("figher2t-03.ibx" for the pictured fighter)? I'm not really sure why the IBX files would affect this, they shouldn't be. |
|
2006-02-10 13:59
|
|
|
|
Here it is. |
|
|
Try as I may, I just can't reproduce this with current code. Even using your IBX file works perfectly for me. Is this still an issue for you in the newer builds? |
|
|
Same as always, unfortunately. 20060228: no lighting without -ambient_factor, horrible lighting without -noibx. |
|
|
Oh, I just realized I should mention this: if I enable -spec but not -ambient_factor or -noibx, I get exactly the same random lighting pattern applied to the spec map. Because I haven't set -ambient_factor, there is no other lighting. So: omitting -noibx causes both regular lighting and specular highlights to screw up in the same way. This is why the lighter parts in the image I posted are so bright (because both specular maps and lighting are being applied to the same spots). Omitting -ambient_factor eliminates shaded lighting. I'm guessing these might be separate bugs. |
|
|
Strange. I'm not using -ambient_factor or -noibx, but I am using -spec and -glow, and it's working perfectly for me. If you don't use any special cmdline options (other than something like -window and -nograb) does it still do the lighting wrong? Were you able to get a debug log that you can attach here? And -ambient_factor is always used, specifying it only uses a different value than the default (which is set to better match retail). |
|
|
Ok, maybe the default value for ambient_factor is just too high for me to notice any lighting, so it appears flat. In which case, this is just one bug relating to IBX somehow. I've attached my debug log from opening the tech room with an empty cmdline file. The lighting appeared flat (due to the standard value of ambient_factor). I've attached a picture too. |
|
2006-03-07 22:26
|
|
|
2006-03-07 22:26
|
HerculesNoCMDoptions.png (47,867 bytes) |
|
|
Does it make a difference if you use 32-bit color instead of 16-bit? |
|
|
Nope, same deal. |
|
|
still an issue? |
|
|
Yup. Still don't know why it happens though. It's by no means an isolated issue, but I haven't been able to replicate it yet. |
|
|
Hmm, I still can't reproduce this and no one else has come forward to tell me that they can. It's either fixed, or just plain no longer an issue. Will reopen at a later time if needed. |
|
|
Found it ... fixed it! It was some issue (still not sure what exactly) where reading info out of an existing IBX file would get incorrect data for the vertex normals. All other info was reading correctly, but with the normals messing up it screwed up all lighting. I changed the way in which is saves and reads this information to the IBX files and that seems to have fixed it. Or at least I was getting 100% of the time, and now I can't get it to happen at all. The fix doesn't break the IBX format, so everything is still compatible. Fixered. |
- Anonymous
