|
2005-05-08 07:51
|
perseus.jpg (51,227 bytes) |
|
|
Any other models causing this? Did you test in D3D? |
|
|
try deleting the ibx in data/cache/fighter2t-03.ibx |
|
|
Yeah, try deleting the IBX. I've seen this a few times in the past couple of months but haven't figured out the problem. Has some type of error during generation which makes it wrong but just deleting the IBX file and letting it regenerate fixes it every thime that I've tried. |
|
|
any updates? |
|
|
Sorry for the delay. I just fired up a mission, and the lines were gone. Looks like it was the ibx file. Thanks for the help |
|
|
Cool. I really wish I new what causes this. The IBX code only writes out what the game generates so it shouldn't actually be the source of the problem, just makes it worse. The IBX code can't really sanity check the data other than to make sure there is enough since that would negate the speed increase that IBX is there for. That buffer generation code just has a few bugs left in it so should this be assigned to Bobboau or just closed? |
|
|
This happens in D3D as well. Deleting the ibx file didn't help as far as I know. |
|
|
my guess would be to check whether the points fall within the radius of the center of a subobject to initially validate the point. It looks like since these lines extend far away from the ship, then that type of check may work. code: rad_sq = bsp.rad * bsp.rad; //alot faster than taking the square root if (vm_vec_mag_squared(input_pt) > rad_sq) { //fail } |
|
|
Nevermind, deleting the ibx file does work. edited on: 05-14-05 02:46 I have confirmed this bug happens with the GVG Anuket as well sometimes. edited on: 05-18-05 13:49 |
|
|
Just an update: I've had this happen to me again once or twice. It seems to work after the initial deletion of the IBX file, but the problem returns the next time I play. |
|
|
Just so I'm sure what you're saying: It's messed up, you delete the IBX, it works fine (should have regenerated the IBX), you exit the game and next time it's messed up again? If that's the case then please attach the IBX to this bug so I can have a look at it. It's supposed to just write what it generates so if it worked right after you deleted the IBX then the working data set should have been written the the new IBX. It never writes again so either there was a problem writing the data in the first place or there is a reading error that I have yet to notice. |
|
|
I just went back and re-checked, and it seems as though everything seems to be working fine now. I'm not really sure why the problem reappeared, but I'll post again if it happens in the future. As a side note, I also noticed that the problem wasn't appearing in every mission with a Perseus in it or every time for a specific mission; there was one particular mission where the problem appeared previously but didn't before, even before I re-deleted the IBX file. |
|
|
Ok. I'm not really sure what to do about this but close it and hope that the math errors get worked out soon. It is rather annoying, I had the same thing happen in TBP last night but with what looked like several models at the same time. Deleting the IBX files fixed it but it was pretty strange. I won't close this until tomorrow at least in case anyone wants to leave it open but this could probably be considered a duplicate of a bug already assigned to Bobboau with the Fenris. I'm relatively sure that it's either closely related to that or a product of the same problem. |
|
|
it seems to be more related to the IBX cacheing than the generation code. are the lines going to the center of the screen all the time (in D3D mode especaly)? if so then this may be a 2d error (some HUD thingy, maybe). does it happen when in external view? |
|
|
The IBX stuff only writes out what find_first_index() and find_first_index_vb() sends back as it gets sent back. It hits those Assert()'s (!= -1, same_vert() check) in generate_vertex_buffers() way too much as well. Supposedly there are problems with NaN values in there. If there is a problem with IBX then ok but I can't say that I see the issue with this though: model->buffer[model->n_buffers].index_buffer.index_buffer[j] = find_first_index_vb(&list[i], j, &model_list); if ( ibuffer_info.write != NULL ) { cfwrite_short( model->buffer[model->n_buffers].index_buffer.index_buffer[j], ibuffer_info.write ); } |
|
|
This should be fixed in CVS now. The problem that was causing this in the generation code should be properly accounted for and fixed the next time the IBX in question gets generated. I'll wait for that to be confirmed before marking as fixed though. |
|
|
The code from fizz seems to have fixed this properly. Reopen if it happens again but be sure to delete the IBX file fist so that it can be regenerated with the proper data. Fixered. |
|
|
the current ibx generation code in the codebase is causing some problems with the comm-node. model and ibx attached. edit: may want to rename those to comm2s-01.* since inferno uses their own naming convention. edited on: 07-05-05 01:29 |
|
2005-07-05 05:27
|
|
|
2005-07-05 05:27
|
|
|
|
Works fine for me. Here's my IBX that got generated exactly the same 12 out of 12 times. They have the same number of verts in them (as does yours) so the basic IBX code is working fine but I don't know why the few bits that are different are that way. Some of the numbers are off by one or two. If it's showing wrong every time, and you tried deleting the IBX already, did it work the time right after you deleted the IBX? |
|
2005-07-05 10:46
|
|
|
|
i've deleted the ibx 3 times and still got the same error. i'll upload a picture. specs: P4 1.8 1gb of ram gf4 ti4200 opengl mode edit: doesn't happen in d3d. also your ibx gives the same problem. edited on: 07-05-05 10:19 |
|
2005-07-05 14:17
|
comm_pic.jpg (23,087 bytes) |
|
|
Renders perfectly fine in OGL for me. And when you deleted the IBX, the very next time you ran it game it still rendered wrong when you first show it in the techroom? If so then it's not an IBX problem since the IBX won't get used until the next time the model get's loaded and you'd have to exit the techroom and go back in for that to happen. And check the log file for any IBX errors just in case. |
|
|
yea i closed out of FS and deleted the ibx and that still happened. i'll check the log file, but i wasn't running a debug and i don't know if it will spit something out then. |
|
|
I just added a -noibx cmdline option so that it will be easier to test/debug this stuff. Still haven't had a rendering problem though, even using your IBX file, so I don't know what to say about that. |
|
|
I think this should be fixed now. If it's the same bug then it was a performance optimization to the VBO which would avoid creating VBOs for small objects to avoid the performance penalty. Going back to having it always create a VBO appears to fix that problem and will likely fix this one too. There was more than one problem here but the VBO issue should be OGL only and wouldn't be fixed by any amount of IBX changing. The other problem was a index buffer generation problem which was making corrupted IBX files but has already been fixed. I think that takes care of this but anyone who makes their own builds give current CVS a try and see if it's still a problem. Everyone else just wait for a newer build and give that a try. |
|
|
Haven't heard anything about this still being a problem with current CVS and everyone else has said that it works. Resolving this again but reopen if it does still happen with the next public build. Fixered. |
- Anonymous
