Page 1 of 2

Having problems with my own mod :/

Posted: Thu Oct 23, 2014 20:45
by Revilution
Right, probably people here already have heard at least of Hunter's Moon, my "Quake 3 on Doom" project that is specifically uses and abuses of OpenGL and GZDoom.

Well, i was going post this on the GZDoom bugs section but after some tests i noticed that the problem is with my mod, but i literally have no idea why GZDoom is crashing with it now, since version g2.1.pre-5-g835dbe5, GZDoom opens and load the mod normally, i checked the starting console for errors but it shows nothing, however when it goes fullscreen and the black screen of loading video, after some seconds it suddently crashes and the log (at least for me) don't point any problem it simply says it crashed.

So, i'm almost begging for help here, because i really have no idea what happened with GZDoom that my mod now crashes it, anyway heres the log i'm saying:

Re: Having problems with my own mod :/

Posted: Thu Oct 23, 2014 21:02
by Graf Zahl
I'll need the mod. The crash has something to do with models, it seems, but without actually seeing it I can't do much about it.

Re: Having problems with my own mod :/

Posted: Thu Oct 23, 2014 23:49
by Revilution
Alright here are the mod, by the way i have to warn that is 150+MB due the "abusive" use of OpenGL i told.

Re: Having problems with my own mod :/

Posted: Fri Oct 24, 2014 0:05
by Graf Zahl
Well, your mod simply runs out of memory. The models are so huge that they totally exceed what can be put into available memory, let alone address space. I had it abort when memory use reached 2GB during some buffer reallocations for the model vertex buffer. Since GZDoom is a 32 bit application, it is limited by 2 GB address space.

Unlike sprites, models are currently not loaded on demand, all existing models get initialized when the engine starts and need to fit into memory.
I may have to implement some caching scheme for model data eventually but that's not a trivial task.

Re: Having problems with my own mod :/

Posted: Fri Oct 24, 2014 0:22
by Revilution
So, there's any suggestion that can i use then? Lower their texture quality, polygons or something of the kind?

Because i'm kinda feeling bad for GZDoom not holding the mod anymore due the general changes you did on the renderer.

Re: Having problems with my own mod :/

Posted: Fri Oct 24, 2014 1:06
by Graf Zahl
It's the meshes of the models, not the textures.

The problems come from using a vertex buffer. In order to initialize that buffer I need a huge pile of memory up front (double the size of the actual buffer.)
With a normal load of models this is hardly an issue but your MD3 files are 180 MB, which easily expand to far above 500 MB when converted into a format the hardware can use directly.

The engine simply was never designed to handle this much model data.

Re: Having problems with my own mod :/

Posted: Fri Oct 24, 2014 1:56
by Revilution
Right then, it simply stopped work?

Back on 1.9 versions the mod was running normally, just now after the overall changes it started this issue, so, from my point all what i can do is pause the development of the mod until that cache scheme don't comes out?

Re: Having problems with my own mod :/

Posted: Fri Oct 24, 2014 8:21
by Graf Zahl
I can't promise anything. The way the model data is currently being handled is just not suitable for this kind of mod. I'll have to try a few things first.

Re: Having problems with my own mod :/

Posted: Fri Oct 24, 2014 8:52
by Revilution
No problem, you already did a good work with the Source Port, also, the mod is not 100% optimized, when i started this i ripped the models of monsters in the first way i found to handle them in GZDoom, however it consists in use only one mesh per animation (one mesh for walking, other for attack, other one for death...), seeing this problem with it makes me want do what i was lazy to do since the last year which is re-rip the models but using only one or two meshes in maximum.

Re: Having problems with my own mod :/

Posted: Fri Oct 24, 2014 10:37
by Graf Zahl
Some good news:

I just rewrote the model code to use separate vertex buffers per model. That avoids the massive peaks that come from reallocating the large CPU-side buffer I previously used. I also delete the model data once the vertex buffer has been set up.
So even without implementing caching, it now works on graphics cards with at least 1GB of video RAM (the vertex buffers eat approx. 300 MB from that but we also need textures and framebuffer so 512 MB are not sufficient.) and a 64 bit operating system, I have serious doubts that it'll work on anything less.

So for now I'll leave it at that, the caching would be far from trivial and unlike the buffer separation not doable in 2 hours.

I got one problem, though: The code for loading DMD models seems broken, I always get crashes on the two ones inside that mod.

Re: Having problems with my own mod :/

Posted: Fri Oct 24, 2014 14:17
by Revilution
Glad to see this, anyway i tried the g2.1.pre-131-gbca47bb right now to see if something happens, still i get the same crashing at start, but until this point have the problem with the DMD models and my system being 32-bit yet.

I'll keep looking on those new builds to see if it works properly as it was doing back on 1.9 versions, well one thing i can say is prolly you will not find anything more heavy than my mod to do bechmarks about every OpenGL feature you put on GZDoom heh :)

Re: Having problems with my own mod :/

Posted: Fri Oct 24, 2014 14:44
by Enjay
What advantages do DMD models have? When working with them, I find them to be an inconvenience in as much as no editing tools support them so, I end up converting back and forth. I assume that there must be some in game advantage (at least in Doomsday).

As a default, I tend to use MD3 anyway.

[edit]
From here: http://dengine.net/dew/index.php?title=DMD
The DMD model format is a custom data format implemented by the Doomsday Engine. A DMD model is similar to a normal Quake MD2 model, but there are two key differences:

Up to four Levels-of-Detail can be specified. LODs are additional triangle mesh sets. Each LOD uses the same set of vertices (which is a bit of a caveat).
Vertex normals are stored in a more accurate fashion, which reduces artifacts in lighting and environment mapping.
Does GZDoom actually benefit from any of that?
[/edit]

Re: Having problems with my own mod :/

Posted: Fri Oct 24, 2014 15:08
by Graf Zahl
They don't have much of an advantage - but since their internal representation is the same as MD2 the entire support for them is one special loader function.
GZDoom doesn't make use of the added LODs. Support is merely there because it's cheap.

Re: Having problems with my own mod :/

Posted: Fri Oct 24, 2014 15:13
by Graf Zahl
Revilution wrote:Glad to see this, anyway i tried the g2.1.pre-131-gbca47bb right now to see if something happens, still i get the same crashing at start, but until this point have the problem with the DMD models and my system being 32-bit yet.
131 doesn't have the changes yet, you'll have to wait until the next dev build. I only started on this stuff after 131 was released last night.

Re: Having problems with my own mod :/

Posted: Fri Oct 24, 2014 15:59
by Revilution
TBH i just took that DMD models from the DS-Models pack, they isn't trivial on the mod so i can remove them or convert to MD3, they are just there because one of my future plans for the mod is make everything that is solid be a 3D Model, they are static so i thought i will never had to touch on them or format because GZDoom supports that extension, so i just ported them from DS-Models.pk3.

And alright sir, i'll wait newer versions to make the tests.

EDIT: just to get rid of future issues with this model format, i already converted them to MD3.