18-06-13, 17:03 | #111 |
Member
Joined: Aug 2010
Posts: 1,810
|
OH MY! This is completely AWESOME!
With Cochrane's version, I got from 3x to 4x (!!!) FPS increase in complex scenes, for example, when full-viewing crater.tr4 (A Witch shall be born), I have 15 FPS with old revision (last TeslaRus' one), and... 60 FPS with latest Cochrane's revision! Now THAT is OPTIMIZATION. However, I've noticed two graphical bugs: first one is well-known mipmap border bleeding bug (so... my eyes are not lying to me, and you have implemented mipmaps? ), and second one is missing colored surfaces in TR1-3. I hope, these are easy to fix. @TeslaRus: I wrote to you in FB about white screen... Do you actually compile latest revision? Here is it. P.S.: Good news is Cochrane's revision fixed skybox bug, which I had for a long time... Some tiles were missing, filled with random colour instead. In Cochrane's version, everything is now OK with them. Good work! Last edited by Lwmte; 18-06-13 at 17:14. |
18-06-13, 17:32 | #112 | ||
Golden
Joined: Apr 2006
Posts: 16,751
|
Quote:
(This is the reason why I added an element buffer for drawing bounding boxes, by the way. Technically speaking, it is absolutely unnecessary, but that way I don't ever have to unbind it.) That's what I wanted to hear! Quote:
Implemented mipmaps was was a single-line code change. The original engine already generates mipmaps, but doesn't set them up properly (specifically: Mipmapping must be set on the MIN filter, while the MAG filter takes only LINEAR. The original code does it the wrong way around). I've also thought about adding anisotropic filtering, but I'd first have to look up whether this might break something on graphics cards that don't support it. I'm not yet sure whether I can do something about the texture bleeding. If not, I'll bypass the texture atlas; it should still run quite a bit faster than the original without it. The colored parts are an interesting issue - I thought about it long and hard during development. Then I started to write this reply and halfway through, I realized I had suddenly worked it out. So I started typing this reply again and noticed no, actually what I had thought of didn't make any sense. So I'll just keep this short: No idea yet where the problem is or how it works in the original; I've got a back-up solution that is definitely going to work, but it's kind of ugly. |
||
18-06-13, 17:43 | #113 | ||
Member
Joined: Aug 2010
Posts: 1,810
|
Quote:
Quote:
|
||
18-06-13, 18:02 | #114 | |
Golden
Joined: Apr 2006
Posts: 16,751
|
Quote:
It would be fairly easy to add padding around each original 256x256 tile, but I don't know whether it would solve the problem. Actually, there's something you could try: In texture_atlas.cpp, line 39 and 40, I'm setting the maximum size for a texture generated by that atlas. If you set that value from 4096 to 256, this will effectively disable the texture atlas (it creates one output page for one input page). Can you tell me whether that still produces acceptable performance and solves the issue? The performance part is more important, because I don't know the performance characteristics of OpenGL on Windows that well. Alternatively, you can solve the issue by disabling mipmaps. In line 134, change GL_LINEAR_MIPMAP_LINEAR to just GL_LINEAR. In my tests, that solves the issue, too. Thanks for the vote of confidence! The problem I have is that the original solution seems to be very elegant, I just don't understand it and hence I don't get why it stopped working. My backup solution is very simple, but requires more texture memory (because I simply texture the colored parts with the correct color). The texture memory isn't that big a problem - I don't think there are that many incredibly huge custom levels for TR1-3 - but exchanging an elegant thing for something like that just feels wrong to me. Last edited by Cochrane; 18-06-13 at 18:04. |
|
18-06-13, 18:21 | #115 | |||
Member
Joined: Aug 2010
Posts: 1,810
|
Quote:
Quote:
Quote:
Last edited by Lwmte; 18-06-13 at 18:22. |
|||
18-06-13, 18:42 | #117 |
Member
Joined: Apr 2013
Posts: 343
|
|
18-06-13, 18:58 | #118 | |
Member
Joined: Jan 2013
Posts: 195
|
climbing, textures
Quote:
About texture atlas... hmmm... Will it be better to generate mini texture atlases: one mesh - one texture and no mipmap problems. +It will be easy to make hi-res textures overrides. |
|
18-06-13, 19:23 | #119 | ||
Golden
Joined: Apr 2006
Posts: 16,751
|
Quote:
I can actually imagine that one working, but that will require a lot of code to find how big the resulting texture atlas should be, how to lay out textures optimally (actually, I'm fairly certain that this may be NP complete in the general case, but with a bounded maximum part size that might be easier), and the ideal border size (actually I think I'd just guess there). I'll think about doing that, but I can't make any promises yet. Quote:
Last edited by Cochrane; 18-06-13 at 19:24. |
||
18-06-13, 21:15 | #120 |
Member
Joined: Apr 2008
Posts: 368
|
I really know nothing about 3d rendering like you guys, but I can't see why mipmapping would necessarily cause bleeding if it's done right?
If I understood right, the atlas feature means that many texture tiles are placed onto one large texture tiles. I once did this to import tut1 into Blender, I packed all of the tiles onto a single 2048x2048 texture. I got texture bleeding in Blender due to the fact that I had calculated uv polygons to be aligned to pixel borders, not to pixel centers, as is the case in tomb4. How are uv coordinates calculated in OpenTomb? |
Thread Tools | |
|
|