0001541: Models not in view/obscured by map geometry are still rendered, causing massive FPS annihilation.

Notes
(0007405) StrikerMan780 (reporter) 2013-10-14 05:43	I'll make another test to see if completely sealed walls produce the same result.

(0007406) Dark-Assassin (administrator) 2013-10-14 06:53	I can confirm this. Also, I believe that some Sprites are also rendered through walls, but only to a limit. This is more an engine limitation AFAIK. Also, from what I heard from SoulPriestess (Eruranna) a while ago is that each Vertex rendered in GZD/ST/Zandro are all dynamic instead of static, which also counts towards massive FPS loss.

(0007407) StrikerMan780 (reporter) 2013-10-14 07:22 edited on: 2013-11-29 02:53	For models, all vertexes should be considered static unless it's an animated model, but they are not, by what you are saying... correct? (I can understand it being dynamic for Doom's geometry, due to how things work there with moving sectors and all.) On an unrelated note... Doom really needs a better Visibility system in general, that functions on both Axis instead of just one. (And some frustum culling, ie. Don't render anything that is outside the camera's FOV.)

(0007439) StrikerMan780 (reporter) 2013-10-19 22:18 edited on: 2013-12-31 09:23	BTW, the framerate annihilation might be part due to the fact that the MD2/MD3 code does vertex and geometry transformation/processing EVERY FRAME in software(CPU), rather than as needed in hardware(GPU) from what I can remember. IIRC, this was a huge waste of performance, and one of the biggest bottlenecks in IDTech 2 and IDTech 3-Based games, which was something that certain source ports fixed, such as ETXreaL. EDIT: Apparently Zandro/GZDoom's model code doesn't use vertex arrays, and instead just uses GL_BEGIN? Would that be part of why performance is so bad?

(0007783) Torr Samaho (administrator) 2013-12-31 09:34 edited on: 2013-12-31 09:36	Vertex arrays could help. Does anybody have time to experiment with vertex arrays in the model code? I'm not sure how well the vertex arrays will work with the interpolation and the movement of actors though. The level geometry the current vertex array code is used for is mostly static.

(0009401) Watermelon (developer) 2014-06-15 14:53	Definitely can confirm this, it ruined a mod idea I had

(0010064) Monsterovich (reporter) 2014-07-28 16:48 edited on: 2014-07-28 16:58	>Vertex arrays could help. Does anybody have time to experiment with vertex arrays in the model code? I'm not sure how well the vertex arrays will work with the interpolation and the movement of actors though. The level geometry the current vertex array code is used for is mostly static. Hm, I made VBO for models sometime, but indices were messed and idk why, it must work anyway.. 'http://s29.postimg.org/axun5xnp3/Screenshot_Doom_20140713_170309.png [^]' Common vertex buffers would help in this situation. That means the same models will be joined in one array. This is more effective than drawing each model from each array and better than glBegin/glEnd shit. The main problem is an animation, because I don't know what I should do with this. Shader animation ftw. :P

(0010066) Edward-san (developer) 2014-07-29 01:09	Can you reproduce on gzdoom glew branch graf is working on? This is the thread, but you should find the latest experimental build in one of the last pages.

(0010073) Monsterovich (reporter) 2014-07-29 07:53 edited on: 2014-07-29 15:48	>Can you reproduce on gzdoom glew branch graf is working on? This is the thread, but you should find the latest experimental build in one of the last pages. No, graf broke opengl 2.* support, new gzdoom branch won't run at all for me. Unsupported OpenGL version. Ha-ha-ha! At least GL 3.0 is required to run GZDoom. Graf'd! I think, he seriously needs a doctor.

(0010075) Edward-san (developer) 2014-07-29 09:10	Since, I suppose, you're not a programmer, I'm not surprised about this reaction. Which graphics do you have?

(0010079) Monsterovich (reporter) 2014-07-29 10:56 edited on: 2014-07-29 11:19	OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce 6200/AGP/SSE2/3DNOW! OpenGL version string: 2.1.2 NVIDIA 304.116 OpenGL shading language version string: 1.20 NVIDIA via Cg compiler Some games (for example: q3-q2 engine based games) have 5x more polygons on ultra large maps. They work faster than GZDoom crap and don't require OpenGL 3.0. * here graf will blame sector engine *

(0010081) StrikerMan780 (reporter) 2014-07-29 11:35 edited on: 2014-07-29 11:36	The old ZDoomGL based on ZDoom 1.22 runs just about as fast on my Voodoo2 card with Creative MiniGL, as GZDoom runs on some modern systems that I've used.

(0010082) Monsterovich (reporter) 2014-07-29 11:46 edited on: 2014-07-29 11:47	>The old ZDoomGL based on ZDoom 1.22 runs just about as fast on my Voodoo2 card with Creative MiniGL, as GZDoom runs on some modern systems that I've used. Try GLBoom, that will show you how GZDoom performance sucks on high-poly maps.

(0010085) Edward-san (developer) 2014-07-29 13:41 edited on: 2014-07-29 13:41	Quote GeForce 6200 Come on, you can find a decent and cheap video cards which have at least OpenGL 3.x support. Quote Some games (for example: q3-q2 engine based games) have 5x more polygons on ultra large maps. That's because these engines have a different rendering algorithm. Doom is not OpenGL friendly at all, because the calculations are done by the CPU for the 90%. You don't know what are you talking about. Quote Try GLBoom, that will show you how GZDoom performance sucks on high-poly maps. prBoom does not need to be compatible with zdoom maps, so its rendering algorithm is naturally faster than zdoom, as zdoom maps do more complicated things which require more conditions to check for the actors in the game. Just give up. You can't improve the performances without using advanced features from recent gl.

(0010086) Monsterovich (reporter) 2014-07-29 15:35 edited on: 2014-07-29 16:30	>>Come on, you can find a decent and cheap video cards which have at least OpenGL 3.x support. What? OpenGL 3.0 release date is: August 11, 2008. That means graf broke support of ALL videocards before 2008. >Doom is not OpenGL friendly at all, because the calculations are done by the CPU for the 90%. You don't know what are you talking about. calculations != optimal rendering >prBoom does not need to be compatible with zdoom maps, so its rendering algorithm is naturally faster than zdoom, as zdoom maps do more complicated things which require more conditions to check for the actors in the game. Prboom & ZDoom? We are talking about OpenGL, because software is very old thing from 90s. (but sometimes it could work faster than gzdoom, ha-ha) Actually, ZDoom maps is not a reason. Let's check performance on vanilia maps then: 'http://www.doomworld.com/idgames/?file=levels/doom2/Ports/0-9/5l1c.zip [^]' For example: this map has no zdoom features, but my fps in GZDoom is 10-5. In GLBoom this map works VERY fast: 52-70 fps. GLBoom renderer is 5-10x faster!! and it doesn't need OpenGL 3.0 to play. My conclusion - GZDoom's renderer is crap. GLBoom is a good example how OpenGL port must work. I guess, if GLBoom had ZDoom features like 3d floors, slopes.., they would work faster, because of good optimization. Finally, everyone is lazy to fork ZDoom and 45% of people have better videocards, where GZDoom is not so laggy, but this will not help to 3d models. :D

(0010089) Edward-san (developer) 2014-07-29 19:05	Quote OpenGL 3.0 release date is: August 11, 2008. That means graf broke support of ALL videocards before 2008. Sorry, but it doesn't sound too much time (6 years is a lot)... Quote calculations != optimal rendering Since GPUs can't do math (except for GPGPU cards), CPUs have to do it, hence the CPU bottleneck. Quote Prboom & ZDoom? We are talking about OpenGL, because software is very old thing from 90s. (but sometimes it could work faster than gzdoom, ha-ha) It was proved by profiling that the major responsible of the difference between glboom and gzdoom is on the zdoom side (really, the renderer is innocent), as proved here. Quote In GLBoom this map works VERY fast: 52-70 fps. GLBoom renderer is 5-10x faster!! and it doesn't need OpenGL 3.0 to play. My conclusion - GZDoom's renderer is crap. GLBoom is a good example how OpenGL port must work. I guess, if GLBoom had ZDoom features like 3d floors, slopes.., they would work faster, because of good optimization. Finally, everyone is lazy to fork ZDoom and 45% of people have better videocards, where GZDoom is not so laggy, but this will not help to 3d models. :D Then prove it. Fork GLBoom and add the ZDoom features. Then let us know if it's really faster than GZDoom. I'm serious. :D

(0010090) Monsterovich (reporter) 2014-07-29 20:05 edited on: 2014-07-29 20:56	>Then prove it. Fork GLBoom and add the ZDoom features. Then let us know if it's really faster than GZDoom. I'm serious. :D Thanks, no, add OpenGL to ZDoom is more easier than add ZDoom to GLBoom. Performance comparison on high poly map: 'http://s23.postimg.org/njzd69gez/opengl_nazi_glboom_gzdoom_perfor_mance.png [^]'

(0010096) Blzut3 (administrator) 2014-07-30 03:39	I do not see how this debate is contributing towards solving the problem, so I will declare it ended here. Monsterovich, if you think it's possible to do better, then write a better renderer. Graf's ability or inability to optimize the renderer is not dependent on people's ability to complain about it.

(0010097) StrikerMan780 (reporter) 2014-07-30 05:34 edited on: 2014-07-30 05:35	The model code of the OpenGL renderer isn't optimized well, as was the original topic of this report. However, if you're talking OpenGL overall, it's mainly the ZDoom engine itself that really needs optimization. However, for that some stuff may need to be rewritten. (Me, personally, would like to see a Vis/Nodes system that works in all 3 Dimensions for geometry culling. It would make large maps a lot more viable when you have big mountains dividing the places up.)

(0010112) Fastclick (reporter) 2014-08-02 22:13	The easiest solution to this problem can be a "render distance" and "3d model render distance" (Like in Doomsday) option. Am i right ?

(0010116) Edward-san (developer) 2014-08-03 16:04	Still, what about the latest builds of gzdoom on drdteam site? Still the same problem?

(0010118) StrikerMan780 (reporter) 2014-08-03 19:07	Same problem.

(0011830) StrikerMan780 (reporter) 2015-03-15 23:52	Looking back on the discussion, the fact that Doom is mostly CPU-bound shouldn't be the primary cause for the Model code specifically to cause such a major performance hit. That is something that can be improved, regardless. The main issue as I can tell, is that the model code does software transformations, plus all models are considered dynamic. I was thinking, could a STATIC flag for MODELDEF be implemented, for models that a modder knows will never move or animate in any way, shape or form, and thus drop any unnecessary calculations in the process? Perhaps apply some form of caching/array/buffer for them since they won't be animating?

(0014144) StrikerMan780 (reporter) 2016-01-21 14:33 edited on: 2016-01-21 14:35	Now that I'm more experienced with OpenGL, having had to write a renderer of my own for Hellbender... I think the best approach here for models labeled as being static, is to store each model into Indexed Elements that can be re-used, translated/rotated when being drawn to the screen as needed for all instances of the model in view. This way the model data is held in GPU memory, there's fewer draw calls, and less CPU->GPU overhead. Also, any immediate mode (glBegin/End) stuff, if still there, desperately needs to be removed. Vertex Arrays for the win.

(0014201) ibm5155 (reporter) 2016-01-25 17:50	But what about making the game to use more than one thread? it could speed up things alot since the problem is zandronum is only using a single core. I can say Graf is trying to make the game faster, but, as said, doom isnt gl friendly, and trying to emulate such software thing in gl is a pain in the ass. And that's why the opengl req from the new gzdoom, because wi gl 4.0 there're better ways to send a bi amount data to the gpu, at the cost of removing potato gpu support

(0014203) StrikerMan780 (reporter) 2016-01-25 17:54 edited on: 2016-01-25 20:10	Doom isn't well-suited to multi-threading. It'd require a huge fundamental rewrite of the game (like Mocha Doom). The only thing that is multi-threaded currently is the sound system, which can be safely separate from the game-sim. Rendering however, cannot. That's irrelevant to this however.

(0014204) Korshun (reporter) 2016-01-25 18:23	This issue is actually two different issues contributing to the bad performance: 1) models behind high walls are rendered even if they can't be seen 2) models are rendered using glBegin/glVertex/glEnd The second issue is particularly egregious. Vertex-animated models should have all their frames uploaded into a vertex buffer and should be animated using a simple vertex shader (OpenGL 2.0 is enough for this) that interpolates between two vertex positions based on time. Instead, they are rendered the most inefficient way possible: by re-uploading the whole model every time it's rendered, EVERY FRAME, and even if THE SAME MODEL is rendered multiple times, EVEN IF IT HAS NO ANIMATION. It's no wonder that rendering a bunch of identical non-animated models causes such an fps drop. Also, this all has nothing to do with multithreading and how fast the rest of zandronum is.

(0014205) StrikerMan780 (reporter) 2016-01-25 20:10	Yeah. It's basically what I've tried explaining in previous posts.

(0014206) Torr Samaho (administrator) 2016-01-26 07:07 edited on: 2016-01-26 07:07	Striker, then please go ahead and rewrite the code with vertex arrays. If you already had to write your own renderer, you should have sufficient OpenGL experience to do this. I'll happily add improvements to the model rendering code and likely Graf will as well.

(0014209) StrikerMan780 (reporter) 2016-01-26 15:36 edited on: 2016-01-26 15:38	It might take a while since I am still busy with Hellbender. (Just so you know I'm not talking out of my ass:'http://puu.sh/kzCpM/334d5c6a9e.png [^]''http://puu.sh/lgS1z/45bfe0d590.png [^]' ) All I need to know is which source file to look at for model drawing. Also, MODELDEF parsing. Any up-to-date compiling instructions too, since last time I checked the Wiki, they were out of date.

(0014210) Torr Samaho (administrator) 2016-01-26 19:17	Quote from StrikerMan780 It might take a while since I am still busy with Hellbender. (Just so you know I'm not talking out of my ass:'http://puu.sh/kzCpM/334d5c6a9e.png [^]''http://puu.sh/lgS1z/45bfe0d590.png [^]' ) Nice! Quote from StrikerMan780 All I need to know is which source file to look at for model drawing. Also, MODELDEF parsing. That should all be in src/gl/models/gl_models.cpp. Quote from StrikerMan780 Any up-to-date compiling instructions too, since last time I checked the Wiki, they were out of date. The VC++ 2005 guide on the Wiki should still be fine. If you have problems compiling, just let me know.

(0014211) StrikerMan780 (reporter) 2016-01-26 20:48	I use Visual Studio 2015 CE. I can't run VS2005.

(0014212) Torr Samaho (administrator) 2016-01-27 18:14	Then you need to use cmake instead of the VC++ 2005 project files. There is a WIP cmake guide:'http://wiki.zandronum.com/User:Csnxs/VSGuide_Sandbox [^]'

(0014213) StrikerMan780 (reporter) 2016-01-27 18:24 edited on: 2016-01-27 18:25	Thanks. When I have some free time I'll take a crack at it. No guarantees since I'm still pretty new, and Hellbender was a good starting point for me since it's code is pretty straightforward C (I hate C++ with a passion), but I'll do my best.

(0016313) Edward-san (developer) 2016-11-24 10:54	Do you mind trying latest gzdoom builds? There should be a huge improvement due to non-moving actors doing uselessly expensive calculations. Of course this won't mean we'll port these improvements to zandronum 3.0.

(0016315) Revilution (reporter) 2016-11-25 00:14	I can say that the lastest GZDoom builds have more stable fps for extensive maps with abusive use of OpenGL features. Here's a screenshot comparison of the most open-field area i did for my mod: 'http://i.imgur.com/Gf52d6W.jpg [^]' In GZDoom the FPS only drops below 30 when there's too many projectiles flying in this area while in Zandronum it is always below 30FPS even if there are no monsters.

(0016317) StrikerMan780 (reporter) 2016-11-25 14:15	Do those areas heavily abuse models as well? Or just other OpenGL features? I will say framerate is better than it was, even with models, but I can't test it thoroughly at the moment since I'm short on time (going on vacation for a while, starting soon).

(0016318) Revilution (reporter) 2016-11-25 17:26	It does, items, weapons in HUD and pickup, monsters and trees are all 3D models, they can't be noticed so much because i resized the image but they are there, this corridor have lots of items and that garden behind the red forcefield have foliage decoration, all of them being 3D models, just the monster count that isn't all that insane due to the map's complexity on this area already getting most of the performance.

(0016740) StrikerMan780 (reporter) 2017-01-31 07:24 edited on: 2017-01-31 07:25	The difference in the latest GZDoom is massive. treetest.pk3 doesn't have a single dip in framerate whatsoever. (1ms difference between models being drawn or not) I see by looking at the source they went ahead and already gotten rid of glBegin/glEnd crap, and are using Vertex Arrays, so what I had planned to do is already taken care of.

Only registered users can voice their support. Click here to register, or here to log in.
Supporters:	Monsterovich Fastclick Korshun ZzZombo ibm5155 djskaarj JC Tenton MaxRideWizardLord JusticeSkulltag
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2013-10-14 05:39	StrikerMan780	New Issue
2013-10-14 05:39	StrikerMan780	File Added: treetest.pk3
2013-10-14 05:43	StrikerMan780	Note Added: 0007405
2013-10-14 06:53	Dark-Assassin	Note Added: 0007406
2013-10-14 07:22	StrikerMan780	Note Added: 0007407
2013-10-14 07:22	StrikerMan780	Note Edited: 0007407	View Revisions
2013-10-14 07:23	StrikerMan780	Note Edited: 0007407	View Revisions
2013-10-14 07:24	StrikerMan780	Note Edited: 0007407	View Revisions
2013-10-14 07:30	StrikerMan780	Note Edited: 0007407	View Revisions
2013-10-14 07:30	StrikerMan780	Note Edited: 0007407	View Revisions
2013-10-14 07:31	StrikerMan780	Note Edited: 0007407	View Revisions
2013-10-19 22:18	StrikerMan780	Note Added: 0007439
2013-10-19 22:21	StrikerMan780	Note Edited: 0007439	View Revisions
2013-10-19 22:22	StrikerMan780	Note Edited: 0007439	View Revisions
2013-11-29 02:52	StrikerMan780	Note Edited: 0007407	View Revisions
2013-11-29 02:53	StrikerMan780	Note Edited: 0007407	View Revisions
2013-12-31 09:23	StrikerMan780	Note Edited: 0007439	View Revisions
2013-12-31 09:34	Torr Samaho	Note Added: 0007783
2013-12-31 09:35	Torr Samaho	Note Edited: 0007783
2013-12-31 09:36	Torr Samaho	Note Edited: 0007783	View Revisions
2013-12-31 09:36	Torr Samaho	Note Revision Dropped: 7783: 0004308
2013-12-31 09:37	Torr Samaho	Note Revision Dropped: 7783: 0004309
2014-06-15 14:53	Watermelon	Note Added: 0009401
2014-06-15 14:53	Watermelon	Status	new => confirmed
2014-07-28 16:48	Monsterovich	Note Added: 0010064
2014-07-28 16:49	Monsterovich	Note Edited: 0010064	View Revisions
2014-07-28 16:55	Monsterovich	Note Edited: 0010064	View Revisions
2014-07-28 16:58	Monsterovich	Note Edited: 0010064	View Revisions
2014-07-29 01:09	Edward-san	Note Added: 0010066
2014-07-29 07:53	Monsterovich	Note Added: 0010073
2014-07-29 07:58	Monsterovich	Note Edited: 0010073	View Revisions
2014-07-29 07:58	Monsterovich	Note Edited: 0010073	View Revisions
2014-07-29 08:04	Monsterovich	Note Edited: 0010073	View Revisions
2014-07-29 09:10	Edward-san	Note Added: 0010075
2014-07-29 10:56	Monsterovich	Note Added: 0010079
2014-07-29 11:03	Monsterovich	Note Edited: 0010079	View Revisions
2014-07-29 11:06	Monsterovich	Note Edited: 0010079	View Revisions
2014-07-29 11:08	Monsterovich	Note Edited: 0010079	View Revisions
2014-07-29 11:08	Monsterovich	Note Edited: 0010079	View Revisions
2014-07-29 11:10	Monsterovich	Note Edited: 0010079	View Revisions
2014-07-29 11:13	Monsterovich	Note Edited: 0010079	View Revisions
2014-07-29 11:14	Monsterovich	Note Edited: 0010079	View Revisions
2014-07-29 11:19	Monsterovich	Note Edited: 0010079	View Revisions
2014-07-29 11:35	StrikerMan780	Note Added: 0010081
2014-07-29 11:36	StrikerMan780	Note Edited: 0010081	View Revisions
2014-07-29 11:46	Monsterovich	Note Added: 0010082
2014-07-29 11:46	Monsterovich	Note Edited: 0010082	View Revisions
2014-07-29 11:46	Monsterovich	Note Edited: 0010082	View Revisions
2014-07-29 11:47	Monsterovich	Note Edited: 0010082	View Revisions
2014-07-29 13:41	Edward-san	Note Added: 0010085
2014-07-29 13:41	Edward-san	Note Edited: 0010085	View Revisions
2014-07-29 15:35	Monsterovich	Note Added: 0010086
2014-07-29 15:38	Monsterovich	Note Edited: 0010086	View Revisions
2014-07-29 15:39	Monsterovich	Note Edited: 0010086	View Revisions
2014-07-29 15:45	Monsterovich	Note Edited: 0010086	View Revisions
2014-07-29 15:48	Monsterovich	Note Edited: 0010086	View Revisions
2014-07-29 15:48	Monsterovich	Note Edited: 0010073	View Revisions
2014-07-29 15:51	Monsterovich	Note Edited: 0010086	View Revisions
2014-07-29 15:52	Monsterovich	Note Edited: 0010086	View Revisions
2014-07-29 16:04	Monsterovich	Note Edited: 0010086	View Revisions
2014-07-29 16:05	Monsterovich	Note Edited: 0010086	View Revisions
2014-07-29 16:06	Monsterovich	Note Edited: 0010086	View Revisions
2014-07-29 16:25	Monsterovich	Note Edited: 0010086	View Revisions
2014-07-29 16:26	Monsterovich	Note Edited: 0010086	View Revisions
2014-07-29 16:27	Monsterovich	Note Edited: 0010086	View Revisions
2014-07-29 16:30	Monsterovich	Note Edited: 0010086	View Revisions
2014-07-29 19:05	Edward-san	Note Added: 0010089
2014-07-29 20:05	Monsterovich	Note Added: 0010090
2014-07-29 20:08	Monsterovich	Note Edited: 0010090	View Revisions
2014-07-29 20:09	Monsterovich	Note Edited: 0010090	View Revisions
2014-07-29 20:56	Monsterovich	Note Edited: 0010090	View Revisions
2014-07-30 03:39	Blzut3	Note Added: 0010096
2014-07-30 05:34	StrikerMan780	Note Added: 0010097
2014-07-30 05:35	StrikerMan780	Note Edited: 0010097	View Revisions
2014-08-02 22:13	Fastclick	Note Added: 0010112
2014-08-03 16:04	Edward-san	Note Added: 0010116
2014-08-03 19:07	StrikerMan780	Note Added: 0010118
2015-03-15 23:52	StrikerMan780	Note Added: 0011830
2016-01-21 14:33	StrikerMan780	Note Added: 0014144
2016-01-21 14:34	StrikerMan780	Note Edited: 0014144	View Revisions
2016-01-21 14:35	StrikerMan780	Note Edited: 0014144	View Revisions
2016-01-21 14:35	StrikerMan780	Note Edited: 0014144	View Revisions
2016-01-25 17:50	ibm5155	Note Added: 0014201
2016-01-25 17:54	StrikerMan780	Note Added: 0014203
2016-01-25 17:55	StrikerMan780	Note Edited: 0014203	View Revisions
2016-01-25 18:23	Korshun	Note Added: 0014204
2016-01-25 20:10	StrikerMan780	Note Added: 0014205
2016-01-25 20:10	StrikerMan780	Note Edited: 0014203	View Revisions
2016-01-26 07:07	Torr Samaho	Note Added: 0014206
2016-01-26 07:07	Torr Samaho	Note Edited: 0014206	View Revisions
2016-01-26 07:08	Torr Samaho	Note Revision Dropped: 14206: 0008572
2016-01-26 15:36	StrikerMan780	Note Added: 0014209
2016-01-26 15:37	StrikerMan780	Note Edited: 0014209	View Revisions
2016-01-26 15:38	StrikerMan780	Note Edited: 0014209	View Revisions
2016-01-26 15:38	StrikerMan780	Note Edited: 0014209	View Revisions
2016-01-26 19:17	Torr Samaho	Note Added: 0014210
2016-01-26 20:48	StrikerMan780	Note Added: 0014211
2016-01-27 18:14	Torr Samaho	Note Added: 0014212
2016-01-27 18:24	StrikerMan780	Note Added: 0014213
2016-01-27 18:25	StrikerMan780	Note Edited: 0014213	View Revisions
2016-11-24 10:54	Edward-san	Note Added: 0016313
2016-11-25 00:14	Revilution	Note Added: 0016315
2016-11-25 14:15	StrikerMan780	Note Added: 0016317
2016-11-25 17:26	Revilution	Note Added: 0016318
2017-01-31 07:24	StrikerMan780	Note Added: 0016740
2017-01-31 07:25	StrikerMan780	Note Edited: 0016740	View Revisions

Relationships