Modernization Kit Beta
by Alex Scarborough · in Torque Game Engine · 02/26/2007 (12:02 am) · 331 replies
Due to the absurd length of this thread, a new one has been started HERE. Please post in the new thread!
This thread is essentially a restatement of this except it's crossplatform now.
I am contractually obligated to do at least one (1) shiny thing a month, so here's my shiny thing for this month:
A working Win32 version of the ModernizationKit.
A huge thanks to OneST8 for getting the port started, and to GG for putting me in front of a PC and not minding that I quietly spent around 20 minutes a day getting this working.
Current version is: v0.8 build 0010 released 4-10-07
This is for TGE 1.5.0/1.5.1 ONLY!
Modernization Kit Website
Username: torqueUser
Password: tMK60152
This code is compatible with the latest version of Mac OS X and Windows 2000/XP
Thanks to the fabulous Jeff "Reno" Raab for letting me host this on the server he runs, and to Ben Sparks for setting up the website and forums!
I can't guarantee this code will work, or even compile, on anything other than my personal computer! Backup your copy of TGE if you use this! Actually, download a clean copy and play with that. I am not responsible for any damage done to your hardware or software as a result of using this!
Some notes: Cg is disabled by default, because it saved me the trouble of shoving Cg into TGE under Windows. Trust me, you're not going to miss the Cg layer anyways, GLSL is where it's at. If you do happen to want to enable Cg for whatever reason, uncomment #define SHADER_MANAGER_USE_CG in mkShaderManager.h.
Unit tests are disabled on Windows, to save the trouble of getting the CppUnit library up and running properly. Unit tests are enabled on OS X because you don't have to do anything for them to work; the bundled project file will link with the compiled dylib, copy it into the application bundle, and even change the install path so you really don't have to do a thing to use unit tests.
This code has not been tested on ATI GPUs under Win32. Presumably it will all work, but who knows. It has been confirmed to at least function on nVidia cards (there are a couple of known issues which will be addressed before 2008).
If you would like to subscribe to the Modernization Kit mailing list, submit a bug, or send some general feedback, please use the links on the Modernization Kit Web Center.
Best of luck, and I hope you get some good use, pretty screenshots, or fun out of this code!
This thread is essentially a restatement of this except it's crossplatform now.
I am contractually obligated to do at least one (1) shiny thing a month, so here's my shiny thing for this month:
A working Win32 version of the ModernizationKit.
A huge thanks to OneST8 for getting the port started, and to GG for putting me in front of a PC and not minding that I quietly spent around 20 minutes a day getting this working.
Current version is: v0.8 build 0010 released 4-10-07
This is for TGE 1.5.0/1.5.1 ONLY!
Modernization Kit Website
Username: torqueUser
Password: tMK60152
This code is compatible with the latest version of Mac OS X and Windows 2000/XP
Thanks to the fabulous Jeff "Reno" Raab for letting me host this on the server he runs, and to Ben Sparks for setting up the website and forums!
I can't guarantee this code will work, or even compile, on anything other than my personal computer! Backup your copy of TGE if you use this! Actually, download a clean copy and play with that. I am not responsible for any damage done to your hardware or software as a result of using this!
Some notes: Cg is disabled by default, because it saved me the trouble of shoving Cg into TGE under Windows. Trust me, you're not going to miss the Cg layer anyways, GLSL is where it's at. If you do happen to want to enable Cg for whatever reason, uncomment #define SHADER_MANAGER_USE_CG in mkShaderManager.h.
Unit tests are disabled on Windows, to save the trouble of getting the CppUnit library up and running properly. Unit tests are enabled on OS X because you don't have to do anything for them to work; the bundled project file will link with the compiled dylib, copy it into the application bundle, and even change the install path so you really don't have to do a thing to use unit tests.
This code has not been tested on ATI GPUs under Win32. Presumably it will all work, but who knows. It has been confirmed to at least function on nVidia cards (there are a couple of known issues which will be addressed before 2008).
If you would like to subscribe to the Modernization Kit mailing list, submit a bug, or send some general feedback, please use the links on the Modernization Kit Web Center.
Best of luck, and I hope you get some good use, pretty screenshots, or fun out of this code!
About the author
#102
I downloaded the kit last night and after a couple of tries got everything to compile successfully. I loaded up the FPS starter mission and entered the appropriate console commands. Things looked beautiful! :)
I did, however, take an immediate and rather severe frame-rate hit down into the single-digits. I exited the mod and reloaded it. Now the ground plane is very, very bright and the water has lost it reflection. Not to mention the extremely low frame-rate.
I'm wondering if compiling as a debug release is part of the reason?
I have a 3ghz processor, a gig of RAM, and my video is a 7800GS with 256mb.
Do you, or anyone else here, have any tips that might help me fix my frame-rate issues?
Thanks.
03/22/2007 (11:09 am)
Hi Alex,I downloaded the kit last night and after a couple of tries got everything to compile successfully. I loaded up the FPS starter mission and entered the appropriate console commands. Things looked beautiful! :)
I did, however, take an immediate and rather severe frame-rate hit down into the single-digits. I exited the mod and reloaded it. Now the ground plane is very, very bright and the water has lost it reflection. Not to mention the extremely low frame-rate.
I'm wondering if compiling as a debug release is part of the reason?
I have a 3ghz processor, a gig of RAM, and my video is a 7800GS with 256mb.
Do you, or anyone else here, have any tips that might help me fix my frame-rate issues?
Thanks.
#103
The reason they appear 'blank' is due to the fact that they're not traditional normal/bump maps. They're setup like heightmaps for the parallax mapping. As such, they use the alpha channel.
Everyone: please submit a bug through the bug report interface. We don't get much of an oppourtunity to happen by here, and we'll help when we can, but we'll notice faster if you submit a bug report.
That said, I cant help you off the top of my head Corey. Have you updated your drivers and all that?
03/22/2007 (12:43 pm)
Eddie:The reason they appear 'blank' is due to the fact that they're not traditional normal/bump maps. They're setup like heightmaps for the parallax mapping. As such, they use the alpha channel.
Everyone: please submit a bug through the bug report interface. We don't get much of an oppourtunity to happen by here, and we'll help when we can, but we'll notice faster if you submit a bug report.
That said, I cant help you off the top of my head Corey. Have you updated your drivers and all that?
#104
03/22/2007 (2:55 pm)
Does it do normal maps for static shapes or just interiors?
#105
It looks like auto-generated images just have RGBA all set to 0... is that correct?
03/22/2007 (3:06 pm)
Ah... so they're not really "normal map" images... i.e. RGB values that make a normal-vector. Are all the "normal map" images like this, or only the auto-generated ones? For example, the one that is provided for the terrain looks like a typical "normal map" in that it has a light blue color (blue is typicially the z-component of the normal vector in a normal map image I guess) and slight variations for the water surface (and no alpha channel). I'm guessing the auto-generated ones are alpha-based heightmaps, but you could set up true normal-maps if you didn't auto-generated them?It looks like auto-generated images just have RGBA all set to 0... is that correct?
#106
@Eddie: The auto generated normal maps contain both normal and height information. The RGB channels contain the normal, and the alpha channel contains the height. The shader expects the normal map to be in this format. However, if render to texture were not working properly on your system the normal maps would likely be set to 0 or complete and utter nonsense, depending on the GL implementation.
03/22/2007 (3:19 pm)
@Dan Keller: As of build 0008, the MK only supports shaders in general on interiors, and generates normal maps for the interiors if none are provided. The same will still be true in build 0009, which I've been meaning to release for a week now.@Eddie: The auto generated normal maps contain both normal and height information. The RGB channels contain the normal, and the alpha channel contains the height. The shader expects the normal map to be in this format. However, if render to texture were not working properly on your system the normal maps would likely be set to 0 or complete and utter nonsense, depending on the GL implementation.
#107
Here's a screany of what I've got...
Happy shading everyone!!!
03/22/2007 (3:54 pm)
Well, I'm happily running the latest revision on stock TGE1.5, I messed a little with stronghold so it's easyer to see the effect...Here's a screany of what I've got...
Happy shading everyone!!!
#108
03/22/2007 (4:57 pm)
Do you have any plane to support shaders on static meshes? Also, does it support specular highlighting?
#109
03/22/2007 (5:50 pm)
I've tried to merge 4 different times now, and even overwritten and compiled that. No luck with any of it, unfortunately. Curse my artist brain!;)
#110
03/22/2007 (8:07 pm)
I get 39 unresolved externals when I try to build with VS2005. I compiles fine, but it can't link.
#111
So you're saying ALL normal maps are really both an RGB "normal map" and an alpha-based "heightmap"... together? Just want to be clear...
Why do I need render-to-texture (which is supported on my system I think - I don't see any "unsupported feature" errors in the console.log I posted above) to do the auto-generation of the normal maps? Isn't the auto-generation just a image-processing sort of thing (i.e. take a greyscale version of the texture map, and produce a combined heightmap/normalmap from it)? The geometry is low-poly, so it's not like we can somehow turn the geometry + texture map into something "cool" like you could do with a high-poly model to compute height/normal info...
I guess I'm just not really understanding the intent of the auto-generated normal maps (other than to fullfill a minimal requirement that the shaders need - i.e. they MUST have a normal-map, regardless of whether it's just flat), or how they could actually be anything more than a "bumpmap" type of thing that is produced via image-processing techniques. What am I missing?
03/23/2007 (9:11 am)
Quote:@Eddie: The auto generated normal maps contain both normal and height information. The RGB channels contain the normal, and the alpha channel contains the height. The shader expects the normal map to be in this format. However, if render to texture were not working properly on your system the normal maps would likely be set to 0 or complete and utter nonsense, depending on the GL implementation.
So you're saying ALL normal maps are really both an RGB "normal map" and an alpha-based "heightmap"... together? Just want to be clear...
Why do I need render-to-texture (which is supported on my system I think - I don't see any "unsupported feature" errors in the console.log I posted above) to do the auto-generation of the normal maps? Isn't the auto-generation just a image-processing sort of thing (i.e. take a greyscale version of the texture map, and produce a combined heightmap/normalmap from it)? The geometry is low-poly, so it's not like we can somehow turn the geometry + texture map into something "cool" like you could do with a high-poly model to compute height/normal info...
I guess I'm just not really understanding the intent of the auto-generated normal maps (other than to fullfill a minimal requirement that the shaders need - i.e. they MUST have a normal-map, regardless of whether it's just flat), or how they could actually be anything more than a "bumpmap" type of thing that is produced via image-processing techniques. What am I missing?
#112
@Dan - I had the same problem initially when I compiled with vc++ee. First I discovered the Modernization kit was not in the project so I added the appropriate files to the project. Then I made sure I had the link libs specified correctly. Viola, everything compiled and linked successfully!
03/23/2007 (11:19 am)
Thanks for the reply Jeff. I'm fairly certain my drivers are up to date, but I'll take a look when I get home today.@Dan - I had the same problem initially when I compiled with vc++ee. First I discovered the Modernization kit was not in the project so I added the appropriate files to the project. Then I made sure I had the link libs specified correctly. Viola, everything compiled and linked successfully!
#113
03/23/2007 (11:39 am)
It should be noted that if you're using VC8(VC++Express, etc) if the modernization kit files don't load when you fire the project up, you can just load the VC7 solution, convert it, and it'll work perfectly. I'm trying to figure out why it's not loading the stuff in the VC8 projects, so in the meantime you can find a solution in that.
#114
Yes. That is exactly what I am saying. It's a pretty common way to store data for parallax mapping.
The MK generates the normal maps on the GPU using a shader. It needs render to texture to do this. The console.log you posted above lists GL_EXT_framebuffer_object (the GL render to texture extension) as unsupported, thus you will not get properly generated normal maps.
Why do it this way? It's faster than any CPU technique available. Seriously. Even on a lowly GeForce FX 5200 the MK can generate approximately three 1024x1024 normal maps per second, and this is with completely unoptimized and highly inefficient code.
The generated normal maps exist to give you a head start on getting your own art up and running. They make prototyping easier (Hey, look, this is what the parallax mapping does, neat!), and since they also generate the necessary scripts they can save you a substantial amount of time. If your game has 400 textures the generated scripts alone are a massive timesaver, much less the time saved by being provided with 400 normal maps ready to use in your game.
03/23/2007 (1:45 pm)
Quote:So you're saying ALL normal maps are really both an RGB "normal map" and an alpha-based "heightmap"... together? Just want to be clear...
Yes. That is exactly what I am saying. It's a pretty common way to store data for parallax mapping.
Quote:
Why do I need render-to-texture (which is supported on my system I think - I don't see any "unsupported feature" errors in the console.log I posted above) to do the auto-generation of the normal maps? Isn't the auto-generation just a image-processing sort of thing (i.e. take a greyscale version of the texture map, and produce a combined heightmap/normalmap from it)?
The MK generates the normal maps on the GPU using a shader. It needs render to texture to do this. The console.log you posted above lists GL_EXT_framebuffer_object (the GL render to texture extension) as unsupported, thus you will not get properly generated normal maps.
Why do it this way? It's faster than any CPU technique available. Seriously. Even on a lowly GeForce FX 5200 the MK can generate approximately three 1024x1024 normal maps per second, and this is with completely unoptimized and highly inefficient code.
Quote:I guess I'm just not really understanding the intent of the auto-generated normal maps (other than to fullfill a minimal requirement that the shaders need - i.e. they MUST have a normal-map, regardless of whether it's just flat), or how they could actually be anything more than a "bumpmap" type of thing that is produced via image-processing techniques. What am I missing?
The generated normal maps exist to give you a head start on getting your own art up and running. They make prototyping easier (Hey, look, this is what the parallax mapping does, neat!), and since they also generate the necessary scripts they can save you a substantial amount of time. If your game has 400 textures the generated scripts alone are a massive timesaver, much less the time saved by being provided with 400 normal maps ready to use in your game.
#115
03/23/2007 (3:05 pm)
I got it to build, but the regular demo thing takes a severe framerate hit (~6 fps in the part with precipitation). I'm running windows with 3GHZ processor, 1GB RAM, geforce 7600 gs graphics card.
#116
03/23/2007 (7:23 pm)
I just discovered that my frame-rate issues are tied to enabling DRL and my screen resolution. If I'm running windowed at 800x600 and enable DRL everything is fine. If I'm running 1280x1024 full screen and enable DRL the gound plane in the Stronghold mission glows so bright it obscures everything else and frame rate drops dramatically. If I just disable DRL I still get nice shiny water and everything else stays nice too. Maybe this will help someone out.
#117
@Corey: That sounds like a VRAM limitation. DRL is a major VRAM hog. I can't run it at resolutions greater than 1024x768 on my 64MB Radeon 9600. I might try and address this in an upcoming build, but absolutely no promises here.
Hmm, this thread is getting to be quite long. Maybe I should look into setting up an MK message board somewhere...
03/23/2007 (9:29 pm)
@All: Hey, build 0009 is available now. Among other things it includes per texture materials! Remember, if you would like to receive email notification of new releases you should subscribe to the Modernization Kit mailing list. Also be sure to checkout the changelog in CHANGES.txt@Corey: That sounds like a VRAM limitation. DRL is a major VRAM hog. I can't run it at resolutions greater than 1024x768 on my 64MB Radeon 9600. I might try and address this in an upcoming build, but absolutely no promises here.
Hmm, this thread is getting to be quite long. Maybe I should look into setting up an MK message board somewhere...
#118
The stronghold map is loading and i can see a difference on interiors for sure, but I get a crash at the lighting phase of loading some of the levels I had laying around that are loaded with both interiors and shapes. Any clues where to start? the console shows it crashes at step 1 of the lighting phase. I didnt include, or use any of the nvidia sdk, but I wasn't planning on using the Cg I tried that in seperate build already.
Im running on xp pro 1gb ram an AMD x2 with a geforce 7800 gt latest nvidia whql pack
Edit:and the water looks fantastic, the ease of use is amazing, the fact that I didnt have to create a single normal map on my own is phenominal.
I know no guarantees come with this one, but any help would be appreciated
03/24/2007 (12:50 am)
Alex, I merged in these changes and ran into a snag, everythign went very smoothly using vs2005 and the vc8 folder and I entered the values in the console to kick it offThe stronghold map is loading and i can see a difference on interiors for sure, but I get a crash at the lighting phase of loading some of the levels I had laying around that are loaded with both interiors and shapes. Any clues where to start? the console shows it crashes at step 1 of the lighting phase. I didnt include, or use any of the nvidia sdk, but I wasn't planning on using the Cg I tried that in seperate build already.
Im running on xp pro 1gb ram an AMD x2 with a geforce 7800 gt latest nvidia whql pack
Edit:and the water looks fantastic, the ease of use is amazing, the fact that I didnt have to create a single normal map on my own is phenominal.
I know no guarantees come with this one, but any help would be appreciated
#119
03/26/2007 (10:48 am)
Weirdly with 00009 I don't have the same DRL issue as before, everything works fine no matter what my resolution! Fantastic resource you guys, thank you! 
#120
I tried 00009 RELEASE on Windows. I run Torque Demo with it. Just There is a speed problem with Modernization kit. I think you will take care of it when optimization phase come.
Any way, Thanks for this cool extension.
Test System: Intel Core 2 Duo 6600, ATI X1300-PRO Radeon.
03/26/2007 (10:59 am)
Hi Alex,I tried 00009 RELEASE on Windows. I run Torque Demo with it. Just There is a speed problem with Modernization kit. I think you will take care of it when optimization phase come.
Any way, Thanks for this cool extension.
Test System: Intel Core 2 Duo 6600, ATI X1300-PRO Radeon.
Torque Owner EddieRay