16-06-13, 19:16 | #91 |
Member
Joined: Jan 2013
Posts: 195
|
Textures
This time implements texture loading only from level file. In the future I will add external textures loading. This time I think about climbing system... maybe It is better to use ghost objects in the climbable places (xor not)...
|
16-06-13, 19:22 | #92 | |
Member
Joined: Jan 2004
Posts: 111
|
Quote:
Still you need to put all transparency polys in his own drawcall, and if you want to implement bump map then that is another switch state and drawcall. maybe you could be interested in some rants i post about this topic: Rendering optimize rant.. Last edited by Turbo Pascal; 16-06-13 at 19:25. |
|
16-06-13, 19:40 | #93 | |
Member
Joined: Jan 2013
Posts: 195
|
Textures
Quote:
Thanks for link, I will read it. |
|
16-06-13, 19:46 | #94 | |
Member
Joined: Jan 2004
Posts: 111
|
Quote:
Ghost objects in the climbable places is obviosly the way used in Crystal Dinamics´s Tomb raiders; but that only works when someone is "doing" the level. In standard clasic Tomb raider levels, climb from floor geometry should no be hard, heights are in 256 multiples values, and there are only about 4 climbing animations/heights well reorganized; if your problem is about sincronizing the climb animation. If you are having troubles i guess it is suporting climbing in static and movables mesh or geometry from meta2tr where heights are non standard, so sincronizing the climb animation will need some nice ajustment to look right. |
|
16-06-13, 19:53 | #95 | |
Member
Joined: Apr 2008
Posts: 368
|
Quote:
The highest number of texture pages I have seen in a level is 1098. It is one of psiko's Hypersquare levels. Last edited by meta2tr; 16-06-13 at 19:56. |
|
16-06-13, 20:09 | #96 |
Member
Joined: Apr 2005
Posts: 9,208
|
What a fantastic job you guys are doing! It would be amazing to get a new engine, up-to-date with modern video games design.
|
16-06-13, 22:44 | #97 |
Member
Joined: Aug 2010
Posts: 1,810
|
Speaking about texture atlas, TP is pointed out that major drawback of it is texture border "bleeding" in mipmaps, which happens because of filtering. What I offered to TP is to extract and filter each tile, and then put it into mipmapped atlas independently. Here is the detailed explanation of this technique. However, it was only a random idea, and I never saw implementation of it in code.
Another, and most widely used technique is to add padding for each tile (clamp it). You can read about it here, or just google "texture atlas mipmapping", and you'll get a bunch of info about this. I guess, this technique is easier to implement, especially in OpenGL. GREAT job with VBOs, I got 2x FPS increase in most scenes, however, RetroFit gives much more FPS in same situations, I guess, it's because it uses shaders? Also, meta2tr levels finally working fine; only big trouble that now persists is the controls lag in some custom levels, which is not related to rendering speed (for example, try to load OT1.tr4 from Armageddon's Temple 2, and you will understand what I'm talking about). |
17-06-13, 04:02 | #98 | |||||
Golden
Joined: Apr 2006
Posts: 16,751
|
Quote:
Transparent polygons and bump map polygons aren't a big problem. There are just not that many of them, so if rendering them is slow, who cares? Getting the normal case optimal is where the big wins can be found. A note about that rant: At least on Mac OS X, it's changes to glEnable state or similar mode switches that hurt a lot; changing the currently bound texture or VBO is not that big a deal. Internally it's all implemented with shaders, so the state changes that hurt are those that require the driver to choose a new shader, or at least check if the current shader is still appropriate. Those that just change the equivalent of uniform values are okay. That may be different on other platforms with other graphics drivers, of course. Quote:
Quote:
Quote:
Quote:
- Indices in VBO, too. - Interleaved vertex arrays (in the buffer). - More triangles per draw call if they all have the same texture. That obviously wins more with the texture atlas, but I'm certain (I'll have to do some experiments) that it also speeds up things a lot without it. In general, there is still way too much redundant state switching between draw calls. I'll try to see whether I can fix that later today. My goal is to get all rendering of textured/colored meshes completely separate from rendering anything that draws lines for debugging. |
|||||
17-06-13, 10:53 | #99 |
Member
Joined: Apr 2008
Posts: 368
|
|
17-06-13, 11:47 | #100 | |
Golden
Joined: Apr 2006
Posts: 16,751
|
Quote:
Edit to add: I've implemented this reduction of state switching, and the performance win was very notable. I'll post this to SourceForge later (currently I'm in a train with only my cell phone as Internet connection). Right now, I'd say that with these changes, the app is as optimal as it gets. There are quite a lot of optimizations that can still be made, but there isn't really any point. It's just a lot of work for no real change in the frame rate. Last edited by Cochrane; 17-06-13 at 15:51. |
|
Thread Tools | |
|
|