Half-Life Model Viewer 2.0 Created 8 years ago2016-08-11 18:01:33 UTC by Solokiller

I've been working on a new model viewer for the past few months. I stopped working on it for a month to work on HL: Enhanced, and i started working on it again today.

It currently provides an entirely rebuilt GUI with all of the options that Jed's Model Viewer has, without the bugs.

The complete list of changes can be found here, as well as the download for the latest version:
https://github.com/SamVanheer/HL_Tools/wiki/Half-Life-Model-Viewer

Today's changes concern the tool startup, shutdown and frame logic. Library loading, interface management and the render loop have all been rewritten to be simpler to use and perform better. Due to changes in how the render loop is performed, the FPS can now go much higher than before.
Testing with several models shows you can get up to ~350 FPS on modern hardware, though high poly models and effects will bring that down a bit.

This approach (idle events) comes at the cost of increased CPU usage, comparable to Jed's (~18% CPU usage maximum on my system). I'm thinking of providing the old loop approach (a timer) as an alternative to provide a low CPU overhead alternative.

I'm going to try and deal with the issues that have been reported on the Github repository's Issues page, though some will be harder than others.

One of the things i want to do is convert the repository's projects to CMake to allow for cross platform compilation. Similarly to HL: Enhanced, this will allow me to target Linux, and project files can be generated for Macs as well if someone has the means to do so.

I was informed that automatic builds are an option, so i'll be looking into that. If i can get it to compile Mac builds, i'll try to get that set up as well.

I've also been experimenting with an interface design that would make it somewhat easy to implement a retained mode renderer. Once everything's in place for that, i'll give it a try. If it works, it should boost performance even more.

Finally, i've also been working on a sprite viewer program. I'm planning to integrate it into model viewer, allowing it to switch between different model render UIs on demand. That'll probably take time though. I've also noticed some strange bugs where some sprites are loaded incorrectly. I'm not sure what's going on there, but it's definitely something i'll be investigating.

If anybody has any thoughts or requests, i'd like to hear them. Do note that i can't get to them all right away since these things will take time. Anything graphics related will need to be designed properly to avoid performance issues.

Interesting. Will it support different render modes? For older graphic cards/chips?

Awesome work, thanks a lot!

@EsprimoP:

You mean supporting older OpenGL versions? That's possible, though retained mode will require 2.0 or newer. It's currently configured for 2.1, but i'll see if i can make it configurable.

@J-M:

Thanks

Sweet! Even though I don't tend to map for Goldsource anymore, I do browse through the models from time to time for one reason or another. I'll be sure to use this version instead of Jed's from now on, especially since you've fixed the bug Jed's has where it doesn't actually stop the process on newer versions of Windows.

Thanks :). I think that bug might still exist in some form in my build, not entirely sure. I fixed one case earlier today while reworking some stuff, and just fixed the other one i know about. My code was relying on automatic cleanup, which didn't work when the program was under heavy load, like rendering a lot of stuff.

I also improved the find command's syntax for '*' characters. Previously, only "find *" triggered special handling by listing all commands.
Now it will interpret * to mean 0 or more characters to skip when comparing characters.
For example, if you wanted to find all commands and cvars that contain "fps", you can do so by entering "fps", but what if you wanted to find something like "framespersecond"? You can now do this by entering the token "*f*p*s*". This will find both "fps" and "framespersecond".

Will you be adding support for the PS2 .dol format like Jed's HLMV? It's a handy feature

Any version below 2.1 is fine, for me. Keep it up.
Oh and sprite explorer, pakscape features would be a lot welcoming.

Amazing!

Did you fix viewer not closing and %100 cpu utilization afterwards bug?

It was noticed long time ago after Jeds release, but havent been fixed (yet) though.

@Urby:

If i can figure out the file format, sure. I tried to reverse engineer it from Jed's and analyze a dol file, but i didn't get very far.

@EsprimoP:

I'll add an option to the settings then. I'll probably have to move settings loading up a bit for this, but that doesn't matter much.

@fuzun:

That bug never really existed here. Both the original HLMV and Jed's have this problem because the GUI framework they use doesn't handle WM_CLOSE messages properly. This is how it handles them:
[quote]
case WM_CLOSE:

if (g_mainWindow)
{
	if ((void *) hwnd == g_mainWindow->getHandle ())
	{
		mx::quit ();
	}
	else
		ShowWindow (hwnd, SW_HIDE);
}
//else // shouldn't happen
	//DestroyWindow (hwnd);
return 0;

[/quote]

It should be calling DestroyWindow here to close the window properly.

mx::quit only sets a boolean. That boolean is used to exit the main loop.
The problem is that it never posts the quit message using PostQuitMessage, so the event queue doesn't exit and keeps the program alive.

As for the CPU usage, that's either a result of the queue not being processed, or the complete lack of a frame limiter in the render loop causing issues:

[quote]
case mxEvent::Idle:
{

g_studioModel.SetBlending (0, 0.0);
g_studioModel.SetBlending (1, 0.0);

static float prev;
float curr = (float) mx::getTickCount () / 1000.0f;

if (!g_bStopPlaying)
	g_studioModel.AdvanceFrame ((curr - prev) * g_viewerSettings.speedScale);

prev = curr;

if (!g_viewerSettings.pause)
	redraw ();

return 1;

}

[/quote]

Without frame limiting, the program will render every time it's idle. I'm using an idle event based renderer too, but it uses the max fps setting to limit the framerate.

If the source for Jed's were available (this is HLMV 1.25's), it'd be relatively easy to fix by adding the call to PostQuitMessage in mx::quit, and making it process messages until it encounters that message in the queue.

Good to hear. A can already see that this is a significant improvement and I've replaced JHLMV. For one thing it's nice to see the animations at more than 10 FPS again.

Great work, Solokiller. Nice to see an improved model viewer.

And I would love a new sprite viewer. Feature requests for this would be ability to create/save sprites, import/export bmp, export all frames to bmp sequence, export to animated gif, and the ability to change the sprite's behavior (parallel upright, parallel, oriented, etc.). Basically combining SprWiz, Sprite Explorer, and SpriteMage into one program.

That's all possible. The current implementation already has code for some of that, but it's unfinished. I'm currently writing CMakeLists for the repository, so expect to see some kind of Linux support soon. I hope it works, but there might be platform compatibility issues.

¿What about loading multiple models in the same viewport?, I mean, load 10 models of the zombie, position them in the space and then link them (something like, "link model" ) with the possibility of making some of their animations (even different animations for each model) start at different times so their movement is more realistic, then you can save the group as a whole model. I´ll pay for that!!, That could be nice for making crowds of npc characters acting in, for example, zombie games (imagine Half-Left For Dead ), of course there is code involved to make that if you kill one the rest of the others don´t die at the same time...

Well i already have the code to place and render multiple models, all i need to do is add a tab to let you select the model and it's done.

Saving models like that is a whole other thing though. You can't have 1 model for multiple monsters.

How much would you pay for that :^)

Hahaha!!!, imagine it!!, no, seriously, I will give ALL credit possible in my MOD for that feature, it will make possible almost a 20% of the work involved in making the action of the game be as I want!!.
Anyway, is your project like Milkshape is?, you can make it so it has more features than a free version if you pay a bit for it, let´s say 5 or 10 dollars... ;), but make it for free, I always put on credits all other´s work.

http://www.moddb.com/mods/zion-warcry/videos/zion-warcry-v-10-credits#imagebox

I'm pretty sure i can't do that without having to pay thousands of dollars in licensing fees. Plus i don't want to make them paid tools.

Oh, didn´t know that. I thought that there weren´t so many legal level requirements when receiving anonymous contributions.

Anyway, I´m sure this project will make a new standard, imagine all possibilities!!, I´m ager to see the final product! (please, do the crowd thingy, please ;D ).

Like i said, you can't have 1 model for multiple monsters. You're going to have to make separate entities that each have the model set. I can let you place multiple models in the world and manipulate them in HLMV though.

I spent today getting the entire repository to work with CMake and on Linux.

I am pleased to say that the transition to CMake has been completed, but Linux support is going to have to wait a bit longer. Some code is dependent on Windows specific filenames and won't work just yet. There may be other issues after that has been solved.

Additionally, the process needed to get wxWidgets to work is quite cumbersome and will need some finetuning. It's currently hardcoded to work only with GTK, and is dependent on version and GUI specific library names. I'll try to solve these issues, but that might not be possible right away.

I've also started using SourceTree, on Penguinboy's recommendation. I find it's a much better frontend for git than Github for Windows, so if you're currently using that, give SourceTree a try.

I've completed the transition to CMake, though there are some problems.

The Linux version compiles, links and runs, but fails to start because the OpenGL code isn't working properly.
On Linux, the default wxWidgets installation uses GTK, which is designed to only create OpenGL contexts if the canvas has been shown. Unfortunately, its definition of shown is "has an X window instance", and for some reason that instance does not exist. Even if i visibly see the canvas on-screen it still refuses to launch.

I've looked into this for a bit, but i've been unable to find out why this happens. I'm going to create a thread over at the wxWidgets forums to ask for help, but if i read some other threads on the topic correctly, then my code will never work due to how wxWidgets' GTK backend is designed.

Other than this problem the HL_Tools codebase compiles just fine, and even loads libraries correctly using the platform's library naming style. I hope that this is the last problem i have to solve, then everything will run on Linux.

Tested it out yesterday, loved it.
Will this support Source models? The model viewer for Source that already exists is really buggy.

I've just installed it 2 days ago, and I must say that it's amazing!
Finally, no more crashes, hlmv.exe not closing after exiting and less CPU usage.
I've been waiting for something like this for years!

Wouldn't you mind if I feature this on GameBanana.com?

@Spreen:

Source models are completely different from GoldSource models. I don't have the time to figure out how that works and how to render those. I'm focusing only on GoldSource.

@Alberto309:

Sure, go right ahead

Thanks mate.

And about other type of models to render with it, you could try with Quake models (md2 and md3 extension). Those ones works similar to Goldsource ones.

Just my two cents eh.

Damn this is nice, definytly using for my work thx ;]

Bloody hell solo, you're an a machine.

If you don't mind me asking, what do you do outside of programming like a champion?

I'm currently in college studying computing. It's pretty much what i'm doing with these projects, except they don't go quite as deep into lower level programming and 3D rendering. I wish i could use these projects for school, last time i did something this big the sheer scale of it was enough to pass.

I'm not going to be very original but this is a great and the greatest HL1 model viewer, thanks Solokiller!

I'm going to learn C++ as part of my studies next year, I wish I'll be able to use my assignments to make some Goldsource-related projects.

Oh, just what is it with these library errors... msvcp140.dll missing error, I can't find the right one.

You need the Visual Studio 2015 redistributable: https://www.microsoft.com/en-us/download/details.aspx?id=48145

Are you sure it's using my HLMV? If you have Jed's installed then it will keep using that until you modify the registry entry to point to my version. I don't know why it does this, probably some broken file association.

Could you generate a heap dump and send it to me? I'll be able to debug it better with that.

You can find how to generate them here: http://forums.svencoop.com/showthread.php/43459-How-to-generate-heap-dumps

It might be necessary for me to recompile it first so i have the debug symbols for it, but i'll try to debug it with just this first.

This seems to be a null pointer exception. Does HLMV's log file show anything strange? It should be in the executable directory.

EDIT: i've compiled a debug version: https://dl.dropboxusercontent.com/u/46048979/HLMV_standalone%20-%20Debug.rar

Could you try this version? If it still crashes, send me the dump file so i can debug it. It should contain all of the information i need.

Sorry about that. Debug builds require different redistributables.

I've recompiled it as a release build. I only need the symbols files anyway, so this should do fine.

Here's an updated download: https://dl.dropboxusercontent.com/u/46048979/HLMV_standalone.rar

There's not much i can do to debug this without some kind of crash information. Can you try generating another crash dump?

The reason i need a crash dump with the new build i gave you is because i don't have the debug symbols for the build you used to generate the old dump file. If you can give me a dump generated with the new build then i can see where it's going wrong and why.

Bumping for thread unlock

Thanks for the bump

So as i said in the engine thread, i added fullbright support and fixed a depth test bug. I'll be refactoring some code first before releasing a new version.

Changing attachments, position of the model, and even the eye position on the fly using the mouse (drag and drop) will be an incredible feature!. =p

Have you got any further with PS2 .dol support? I asked Jed many years ago how the format differed and it's apparently the same as Half-Life except the textures are swizzled (see http://ps2linux.no-ip.info/playstation2-linux.com/download/ezswizzle/TextureSwizzling.pdf).
Any chance of Dreamcast .mdl support too? I suspect that all Dreamcast .mdl files use only two of the twelve or so different .pvr formats.

I haven't worked on model viewer that much lately, i've been focused mostly on HLE. If i can figure out what the model format is like i might be able to do it, but i'll probably need to rework the viewer's implementation for that.

Bump

I released a minor update: https://github.com/SamVanheer/HL_Tools/releases/tag/V2.1

Glad to see a new update!

One thing I found interesting was that "$flags 128" has a different appearance in vanilla HL as opposed to XASH. For example in Xash its the "purple trail" and in regular it looks like a single burning trail.

I wrote a long description of all the $flags in this page here including what exact quake effects they are:
http://the303.org/tutorials/gold_qc.htm

I checked the code for that flag; Xash has the same code as Quake, but the engine has a different color algorithm so it ends up different.
It also handles lifetime and overall effects settings differently, so this is something that needs to be updated in Xash.

Yes, the shockwave effect of the houndeye shows a plain blue-ish color instead of the shockwave sprite :/

That's done using temporary entities, not model flags. You're probably using the wrong sprite for it.

Oh, no, not at all, the sprites folder and the code is untouched since it worked 100% in 2015. The only thing that has changed was the Xash dlls...
Also, additive sprites now show the black parts instead of being transparent when usted as sprites for effects in explosions of NPCs like the turrets, the Hornets, and the overheat effect of the weapons of my mod, but they worked fine if used as env_smoke.

Xash has some odd quirks, I noticed that animated sprites (env_sprite) flicker for some reason. I posted a bug report on the MODDB page a while and the guy there said he would take a look into it.

So i've been working on HLMV for the past few days:I've replaced the UI with Qt. Only the UI part is actually functional, no backend functionality has been implemented yet.

Does this look good compared to 2.0?