[StratComm]

People ask that it be more pronounced so that they can say "oh look, environment mapping" but then get used to it and expect it to be that way.  It should be very subtile, especially given the way most of the FS ships are beaten to hell and back.  And then there's the fact that this isn't even tweaked in the game code, but is actually a media issue entirely.  Lower or raise the intensity of the alpha channel on a map and presto, you've changed the reflectivity.

[neoterran]

People ask that it be more pronounced so that they can say "oh look, environment mapping" but then get used to it and expect it to be that way.  It should be very subtile, especially given the way most of the FS ships are beaten to hell and back.  And then there's the fact that this isn't even tweaked in the game code, but is actually a media issue entirely.  Lower or raise the intensity of the alpha channel on a map and presto, you've changed the reflectivity.

QFT

[Mars]

...especially given the way most of the FS ships are beaten to hell and back.

Hadn't thoght of that, your right, it is about right.

[Ferret]

Env mapping = Sexy. Great job on it!

[taylor]

lol, well taylor, you knew this would happen. This is why perhaps you should have left parameter passing for this feature in so that people could tweak it.

I did keep a copy of the cmdline.cpp file which has the options in it, just in case.  The problem is that the intensity of the effect depends on the textures.  Maps that aren't as good will look too intense, ones that were trying to fix the D3D version will be too dull.   I tested every mod/model/texture I could get my hands on before settling on the current levels and that just worked the best.  Everyone who has tested it so far has liked where it is now, though I didn't actually expect that, so I'm resistant to chaning the values now.

It may turn out that putting the scale cmdline options back in is a good idea but I didn't want to do that until after it had been in use for a little while.  I'm not going to change the defaults, but I may add the options back sometime next week.

Still trying to figure out what the super secret add on is...

Ok, one more hint:  What act is closely tied to a food item, that when properly prepared, is consumed from a small bucket?

If you can't get it now, I give up.

[neoterran]

This thread has gone seriously off topic (thinking it needs a new name: Taylor's Env Mapping Build, (Was : Updated HUD))

Your build has also provided me with some performance improvements, Taylor. Not in FPS, but there is no more pausing / hitching behavior AT ALL for me any longer on my abused 5600 Ultra. It had already been seriously mitigated by the DDS mediavps_t, but now it is really completely gone. Although this card is a 4 x 1 card that has terrible DX9 and Shader performance due to Nvidia's royal cock-up, it actually performs extremely well in OpenGL, where it doesn't suffer anywhere near as serious problems as it does in Direct X. In fact I'm able to run playable frame rates with 8xS AA and 8x AF which is pretty outrageous, (but it looks great)

[Psychonaut]

lol, well taylor, you knew this would happen. This is why perhaps you should have left parameter passing for this feature in so that people could tweak it.

Yeah, thats the reason for feedback. And thats also the way things work in an community. Just in case you forgot this, neo.

[Gregster2k]

I think I figured out what the super secret addition is:

Save Render Targets to File? (under Dev Tools, of the launcher flags)

[taylor]

I think I figured out what the super secret addition is:

Save Render Targets to File? (under Dev Tools, of the launcher flags)

Nope.  That's just a standard part of the envmapping support that I added.  This is for modders to save the envmaps generated by the game to file.  Then they can enhance/compress them and distribute the files as part of the mod/mission data.  There is a new mission flag ("$Environment Map:") which lets them specify a file to use for the envmap.

When you enable that option (-save_render_target) then it will save the generated envmaps, and other static render-targets, to data/cache/ so that you can pick over them later.  So when the ship/weapon select screens are modified to use the render-to-texture support to turn 3D models into icons, the mod maker can save those images and use them as the icons for the ship/weapon.  And since the OpenGL extension required to make envmaps in-game isn't going to be supported for everyone, this lets them still get to use envmaps since they already exist.

As an added benefit of this, it can save a ton of memory.  When an envmap is created by the game it's uncompressed.  With the default settings that means that the envmap is using about 6megs of memory.  But if the mission maker was kind enough to distribute an envmap which was already created, and compress it with DXT1, then it would need only 1meg of memory.  Plus the saved envmap could be enhanced to highlight certain portions or some parts even removed.  Hell, you could make a totally new envmap from scratch, or from images downloaded from NASA, and use that instead of relying on the game to do it for you.

[Turambar]

so i could also put in say, a large static ship, or meshes that otherwise wouldnt be put in by the game, but that would only look right if said mesh didn't move and was a good distance away, and i'd just have to draw it in right.

sounds good. 

[Shade]

Found the feature. Very nice

[Trivial Psychic]

Taylor, I hate to jump right to the bad, but your FRED build isn't displaying backgrounds.

[taylor]

Taylor, I hate to jump right to the bad, but your FRED build isn't displaying backgrounds.

Hmm, I never even tested it.  Mainly just included it to make sure I didn't break building for anyone else.  If you are using -env with FRED2 then try removing that and see if it makes a difference.  Since -env never worked with FRED2 before I did kind of question whether it was safe or not.  The other change that could be causing the problem (and is more likely) is that I removed all of the view/projection matrix setups from the starfield code.  It's a serious performance drain to set and unset that stuff so many different times per frame.

FRED2 likely just doesn't have the base view/projection matrix setup before calling stars_draw() and that would cause it to render incorrectly.  Phreak would probably know that better than me, but the fix should be simple enough.  I think that a couple of HTL functions were added for FRED2 (fred_enable_htl() and fred_disable_htl()) so any calls to stars_draw() just need to be wrapped in that.  If neither Phreak nor karajorma do that before I get the chance I'll take care of it in a couple of days.  Feel free to file a Mantis bug on it though, I bet that karajorma is planning to release a new FRED2 build soon anyway.

[Trivial Psychic]

Its not the stars.  If I adjust the star number slider, I can see it having an effect.  It will also display any suns in the mission, it will however refuse to display any nebulae or skyboxes.  You can sometimes see a very thin crescent at the edge of the viewing window, which may be a distorted render of the background.  This occurs whether -env is enabled in the shortcut or not.  Also, the debug build (FRED) is giving me some weird errors for missions I've been working on for TBP:

Assert: GL_modelview_matrix_depth == 2
File: c:\documents and settings\taylor richards\desktop\fs2_open.pre\code\graphics\gropengltnl.cpp
Line: 1092

Assert: GL_htl_projection_matrix_set
File: c:\documents and settings\taylor richards\desktop\fs2_open.pre\code\graphics\gropengltnl.cpp
Line: 975

In fact, even if I start from scratch, and attempt to place a nebulae (in debug FRED), I'll get the first error message.

Can you translate these?

[Ferret]

Isn't that an old FRED bug that was there for months and got knocked out not long ago?

[taylor]

Its not the stars.  If I adjust the star number slider, I can see it having an effect.

The stars themselves aren't HTL which is why they work fine.  But stars_draw() will draw the skyboxes, background nebula, subspace, suns, and the stars.  It's only the parts that are rendered using HTL that will break.  Those Assert() messages are just confirming the problem, that the view and projection matrix isn't set.

[karajorma]

Isn't that an old FRED bug that was there for months and got knocked out not long ago?

I don't think so. FRED is asserting with this message when I try to open some earlier missions I made for SoR with this error.

Assert: GL_htl_projection_matrix_set
File: d:\c++\freespace\fs2_open\code\graphics\gropengltnl.cpp
Line: 975

and it didn't do that last time I tried the mission (which must be a couple of weeks back). I'll probably take a look-see what's causing that at some point but I've not poked around in the graphics code at all yet so I probably won't have a clue what's going on there.

[taylor]

I'll probably take a look-see what's causing that at some point but I've not poked around in the graphics code at all yet so I probably won't have a clue what's going on there.

... I think that a couple of HTL functions were added for FRED2 (fred_enable_htl() and fred_disable_htl()) so any calls to stars_draw() just need to be wrapped in that. ...

[karajorma]

Didn't help. I'm not really any the wiser about what the code is doing after looking at it and I'm really loathe to alter code when I don't have a clue what it's doing.

[taylor]

Didn't help. I'm not really any the wiser about what the code is doing after looking at it and I'm really loathe to alter code when I don't have a clue what it's doing.

Hmm.  I thought that just changing:

Code: [Select]

if ( Bg_bitmap_dialog ) {
    stars_draw( Show_stars, 1, Show_stars, 0, 0 );
} else {
    stars_draw( Show_stars, Show_stars, Show_stars, 0, 0 );
}to:

Code: [Select]

fred_enable_htl();
if ( Bg_bitmap_dialog ) {
    stars_draw( Show_stars, 1, Show_stars, 0, 0 );
} else {
    stars_draw( Show_stars, Show_stars, Show_stars, 0, 0 );
}
fred_disable_htl();in fredrender.cpp:1777 should fix it.  If that's not what you did then try it and see what happens.  I don't want to make that change in CVS until I can actually test it, and that isn't likely to happen until tomorrow night sometime.  If that turns out not to help any then I'm not really sure what the issue is.  I don't remember changing anything else that could have caused this particular error.