Tomb Raider Forums  

Go Back   Tomb Raider Forums > Tomb Raider Level Editor and Modding > Tomb Raider Level Editor > Software Development

Reply
 
Thread Tools
Old 18-06-13, 17:03   #111
Lwmte
Member
 
Lwmte's Avatar
 
Joined: Aug 2010
Posts: 1,810
Default

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.
Lwmte is offline   Reply With Quote
Old 18-06-13, 17:32   #112
Cochrane
Golden
 
Cochrane's Avatar
 
Joined: Apr 2006
Posts: 16,751
Default

Quote:
Originally Posted by TeslaRus View Post
I saw the Cochrane's code - great work! Immediately feeling other code style . I was trying to build project with the texture atlas optimization... Only white screen. I check (with debug) VBO generating function - all correct (but I mean it will be good to add one string to the end:
Code:
glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, 0);
), but screen is white (console is working). Now I update climbing functions code and CVARs has a set callback.
That additional code is actually not necessary. There are only two parts where the code could possibly encounter the element array buffer because glDrawElements is used: Once when drawing meshes, and once when drawing bounding boxes. In both cases, I make sure to bind a valid element buffer first. All other drawing via glDrawArrays or glBegin doesn't use the element buffer anyway, so it does not matter which buffer is bound.

(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.)

Quote:
Originally Posted by Lwmte View Post
OH MY! This is completely AWESOME!
That's what I wanted to hear!

Quote:
Originally Posted by Lwmte View Post
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.


Yes, that bleeding bug is annoying. Actually, I'm not fully convinced that disabling mipmaps will make it go away; it might even become worse if I understand the maths behind it correctly (but I don't actually, so who knows).

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.
Cochrane is offline   Reply With Quote
Old 18-06-13, 17:43   #113
Lwmte
Member
 
Lwmte's Avatar
 
Joined: Aug 2010
Posts: 1,810
Default

Quote:
Originally Posted by Cochrane View Post
Yes, that bleeding bug is annoying. Actually, I'm not fully convinced that disabling mipmaps will make it go away; it might even become worse if I understand the maths behind it correctly (but I don't actually, so who knows).
I can assume that the only reason for this bug is mipmapping, because same thing happened with FexEngine 3 years ago; only solution for this is to generate padding around each tile, which requires some calculations to filter out smaller texinfos inside larger tiles... I'm not sure if it worth a try, however... How many contemporary 3D games actually use texture atlas?

Quote:
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.
I'm sure that you'll eventually find a proper solution for this, because I know this feeling you've described!
Lwmte is offline   Reply With Quote
Old 18-06-13, 18:02   #114
Cochrane
Golden
 
Cochrane's Avatar
 
Joined: Apr 2006
Posts: 16,751
Default

Quote:
Originally Posted by Lwmte View Post
I can assume that the only reason for this bug is mipmapping, because same thing happened with FexEngine 3 years ago; only solution for this is to generate padding around each tile, which requires some calculations to filter out smaller texinfos inside larger tiles... I'm not sure if it worth a try, however... How many contemporary 3D games actually use texture atlas?
It's actually recommended on many mobile systems, but I have no idea how many games actually do that. It's certainly a lot in 2D. As for modern PC games, none of them do, but they typically have large textures anyway, and make sure that each mesh has only one texture (per texture kind) associated with it.

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.

Quote:
Originally Posted by Lwmte View Post
I'm sure that you'll eventually find a proper solution for this, because I know this feeling you've described!
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.
Cochrane is offline   Reply With Quote
Old 18-06-13, 18:21   #115
Lwmte
Member
 
Lwmte's Avatar
 
Joined: Aug 2010
Posts: 1,810
Default

Quote:
Originally Posted by Cochrane View Post
It would be fairly easy to add padding around each original 256x256 tile, but I don't know whether it would solve the problem.
The problem is, you not only need to set padding for 256x256 tile, but for each tile with different adjacent "material". Since TR levels (especially custom ones) can have various texinfos refering to the same tile, you need to scan each texinfo and find whether it belongs to a tile with larger texinfos refering to it ("parent" texinfos) or not; and when you'll find largest texinfo for this tile, effectively it will be the "parent" tile you need to apply padding to; also, you must correspondingly correct all "child" texinfos coordinates inside padded "parent" tile.

Quote:
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).
Nope, it doesn't solve border bleeding problem. The problem will exist anyway, because engine will still refer to whole texture pages (256x, 4096x... no matter).

Quote:
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.
I believe that disabling of mipmaps is a very brutal and ugly solution, because Core Design used this solution for all their TR1-5 games on PC, and people are really tired of "ringing" texture noise which appears on far distances... So another solution must be found... Also, seems that shabtronic found a solution for his RetroFit engine, because it has mipmaps without bleeding bugs. (I suppose, he simply treated each texinfo as unique texture, but maybe he came up with something similar that I described above - we need to get in contact with him, however, he's not active and doesn't appear on this forum anymore).

Last edited by Lwmte; 18-06-13 at 18:22.
Lwmte is offline   Reply With Quote
Old 18-06-13, 18:42   #116
-Roli-
Member
 
-Roli-'s Avatar
 
Joined: Jul 2007
Posts: 5,494
Default

Quote:
Originally Posted by Lwmte View Post
we need to get in contact with him, however, he's not active and doesn't appear on this forum anymore).
Try on his youtube channel, there he is more active.
-Roli- is offline   Reply With Quote
Old 18-06-13, 18:42   #117
Ado Croft
Member
 
Joined: Apr 2013
Posts: 343
Default

Quote:
Originally Posted by TeslaRus View Post
Now I update climbing functions code and CVARs has a set callback.

Are you updating climbing functions from Floor Data?
Ado Croft is offline   Reply With Quote
Old 18-06-13, 18:58   #118
TeslaRus
Member
 
TeslaRus's Avatar
 
Joined: Jan 2013
Posts: 195
Default climbing, textures

Quote:
Are you updating climbing functions from Floor Data?
No, I find edge by planes equations, normales a.t.c.... This time It is only sources on SF... The algorithm is correct, now I need to tune one.

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.
TeslaRus is offline   Reply With Quote
Old 18-06-13, 19:23   #119
Cochrane
Golden
 
Cochrane's Avatar
 
Joined: Apr 2006
Posts: 16,751
Default

Quote:
Originally Posted by Lwmte View Post
The problem is, you not only need to set padding for 256x256 tile, but for each tile with different adjacent "material". Since TR levels (especially custom ones) can have various texinfos refering to the same tile, you need to scan each texinfo and find whether it belongs to a tile with larger texinfos refering to it ("parent" texinfos) or not; and when you'll find largest texinfo for this tile, effectively it will be the "parent" tile you need to apply padding to; also, you must correspondingly correct all "child" texinfos coordinates inside padded "parent" tile.

Nope, it doesn't solve border bleeding problem. The problem will exist anyway, because engine will still refer to whole texture pages (256x, 4096x... no matter).

I believe that disabling of mipmaps is a very brutal and ugly solution, because Core Design used this solution for all their TR1-5 games on PC, and people are really tired of "ringing" texture noise which appears on far distances... So another solution must be found... Also, seems that shabtronic found a solution for his RetroFit engine, because it has mipmaps without bleeding bugs. (I suppose, he simply treated each texinfo as unique texture, but maybe he came up with something similar that I described above - we need to get in contact with him, however, he's not active and doesn't appear on this forum anymore).
The solution you propose can quickly degenerate into pure chaos. A texinfo can intersect any number of other tex infos, so there's no clear parent-child relationship. It's not even a directed acyclic graph. I think the only approach to this that would reliably work in all cases is what you guess shabtronic did for the RetroFit engine.

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:
Originally Posted by TeslaRus View Post
No, I find edge by planes equations, normales a.t.c.... This time It is only sources on SF... The algorithm is correct, now I need to tune one.

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.
Interesting idea. It'll involve a bit more computation work, but it's definitely doable. The question is whether it'll provide big advantages.

Last edited by Cochrane; 18-06-13 at 19:24.
Cochrane is offline   Reply With Quote
Old 18-06-13, 21:15   #120
meta2tr
Member
 
Joined: Apr 2008
Posts: 368
Default

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?
meta2tr is offline   Reply With Quote
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



All times are GMT. The time now is 12:30.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.
Tomb Raider Forums is not owned or operated by CDE Entertainment Ltd.
Lara Croft and Tomb Raider are trademarks of CDE Entertainment Ltd.