ZDoom

Would love to make use of the PBR System that is now available in gzDoom. However I still cannot get models to appear correctly (mapped to their textures) without Zandronum. I have written a more in depth message at Doomworld with pictures.

Please have a look here: Read at Doomworld (Thread removed)

Hope someone can help, thanks for your time.

I doubt that it’s possible to help without looking at model in question.

Here's a 50k poly geoshpere made in 3d studio max. Then exported to obj / open in misfit model 3d / applied texture / made a single frame / export as md2.

Here's the results..
A: Misfit Model 3D
B: gzDoomBuilder
C: gzDoom 4.2
D: Zandronum 2-3

Here's the files for you to test yourselves...

50kPolyTest.zip

Viper wrote:A: Misfit Model 3D

I know this doesn't directly address your issue, but Maverick Model 3D is a more up to date (and still occasionally maintained) version of Misfit. It contains a number of bug fixes.

https://clover.moe/mm3d/

I have plugins for 3dstudio for Md2 importing/exporting now, so misfit isn't needed anymore but thanks I didn't know about Maveric Model 3D.

Hoping Graf Zhal can shed some light on this..

I can't check right now but considering that both GZDoom and GZDoomBuilder show the same glitch it strongly hints at a problem with the model.
What you should know is that MD2 models contain two separate versions of the mesh - one made of triangles (the one GZDoom uses) and one made of OpenGL draw commands - this was used by the old renderer which still gets used by Zandronum. It looks like the triangle table in your model was not exported correctly.

Export to md3. It's light years ahead of md2. GZDoom works great even with models that have more than 1 million of polys, the only limiting factor here is your graphics card, memory and CPU.

It seems to be an index overflow as this model has 150'000 texture coordinates.

You mean index overflow in the model or in the code creating a mesh from it?

In the model, indices are 16-bit integers.

Thanks for all the replies, it's an honor to "talk" with Graf finally, been meaning to ask this for a very long time.

Models this high of polycount can't be exported as MD3, I believe the limit is roughly 4000 per group.

The general code to export models to MD2 format seems to be the real issue, as it skips vertices that are too close together, the exporter plugin with 3ds max has the same result. So Zandronum must be using the old rendering method to read the model, which is odd that the old method works better in this case (due to the way md2's export), wonder why the new method doesn't work? Perhaps it's hard to explain, in which case I ask how hard would it be to change a version of gzDoom to read the "other" model within the md2? If not my backup plan would be to see if I could add the shader files to Zandronum for DOOM GTS, as I see it looks for a lot of the same files. If the "old method" is GL based, could it too support these new shaders or is there more to it that that? I would much rather use gzDoom don't get me wrong, as it is not focused on mulitplayer, but were talking about hundreds of frames worth of no-tweening manually animated models. Which is a laugh to think about redoing.. (See below) Keep in mind part of the goal with DOOM GTS is to push the old system to limits.. (not in a laggy way).

See here to get an idea of the amount of work were talking about: (Speedrun)

Viper wrote: The general code to export models to MD2 format seems to be the real issue, as it skips vertices that are too close together, the exporter plugin with 3ds max has the same result. So Zandronum must be using the old method to read texture coordinates, which is odd that the old method works better in this case, how come the new method doesn't work?

It doesn't work because the index field is too small (2 bytes instead of 3 and 4)
The draw commands stored in the model use the vertices directly without indexing them. Unfortunately that means it's of little use for a modern renderer because it needs to do a lot more work to turn that thing into something usable, i.e. create the index table itself. On the other hand, MD2 is really not recommended format, it has far too serious issues and should be avoided if possible. Support is there because this code was initially added to load mods made for Vavoom which contained MD2 models.
Had I done this from scratch I doubt I'd have supported this format.

Appreciate,the quick response. I don't disagree about the format haha, but to my knowledge its that or MD3, which is a no-go as stated above. Are there other animation formats that are supported besides md2/md3?

There are no other formats, no. I recommend using Nash's MD3 exporter. I believe GZDoom lifts said limit (as it's an artificial limit, not a real one), and so does Nash's exporter.

Problem is solved. Thanks to Enjay mentioning Maverick Model 3D and phantombeta for letting me know MD3 files can handle higher polycounts... I thought I'd see if Maverick Model has taken the limit off of the md3 exporting process since its possible and sure enough, it exported it, took a minute but it did it, perfectly , Night and day difference.. People waiting to play this are going to be in for a treat now,

Zandronum 3 is just no comparison to gzDoom 4.2, hope they don't read this but the performance and graphics quality are far superior. Bonus, more code is available to me. I am going to be very busy..

Graf I say thanks for the quick help, you did answer my question as to what the real reason was, and without it, I'd be left confused. Wonderful piece of software gzDoom is, very glad I finally get to move into it.

DOOM GTS will now be strictly run on gzDoom 4.2.

Many models are going to come to life, I cannot wait to setup the mastermind with his brainy bump map.

*Looks like it was just 2 days ago that Maverick Model had this fix.. See line 4 ChangeLog