TDM versus TDS

[Baal]

it doesn(didnt?) run well under Linux

I'm running System Shock 2 with a recent version of wine and a Radeon 4650 on the catalyst drivers. Runs fine. Maybe Thief is playable now too.

[Trickster]

Well, that´s Thief2 with enhancement-textures and the latest ddfix with Bloom:

I adjusted the bloom so that it´s only slightly, how it should be. By default it´s really heavy...

 

how the hell do you adjust bloom ? my ddfixed T1 doesn´t show any...

there are some bloom settings in ddfix.ini, but no "bloom enable=1"

is it enabled by default ? can´t see it ingame...

here´s how my ini looks like, would you point me what settings to modify ?

 

[Main] ;Screen resolution ;Must be 800x600 or greater gWidth=1024 gHeight=768 ;Refresh rate. 0 is default, anything else to override. RefreshRate=0 ;Set to 1 to fix the duel core related crash MultiCoreFix=1 ;Set to 1 to automatically register lgvid.ax each time thief is started up VideoFix=1 ;This can be set to zero to get a more accurate z-buffer ;Doesn't usually make a noticable difference to picture quality UseCompatibleZBuffer=1 ;Turns on the 32 bit texture loader ;This is also required by global fog autodetection TextureReplacement=1 ;Set to 1 to disable the windows keys while thief is running DisableWindowsKey=1 ;Set to 1 to enable anisotropic filtering AnisotropicFiltering=1 ;If you want to share overriden textures between thief installations, uncomment the next line ;It should contain the absolute path to the equivilent of \res\ddfix, including the trailing \ ;TexturePath=C:\Games\Thief2\res\ddfix\ ;Triple buffering. Boolean. (Default 0.) ;TripleBuffer=1 ;Number of vsyncs per flip. Increase this number to decrease frame rate. 1-4. (Default 1.) ;FlipInterval=2 ;Frame rate limit in frames per second. Float. (0 = unlimited.) ;FrameRateLimit=87 ;Menu screen update delay in milliseconds. This is needed only if vsync is off. ;(Default 0, 0 = no delay.) ;MenuUpdateDelay=14 ;Menu/video screen aspect ratio. Float. (Default 1.333, 0 = fullscreen.) ;MenuScreenAspect=0 ;Changes the way direct writes to the frontbuffer are handled ;SS2 players should set these options to '2' and '0xf81f' respectively ;Thief 2 players with corrupted in game text should use '2' and '0x0000' ;Players who experience slowdown with UseSysMemOverlay=2 should set both options to 0 ;UseSysMemOverlay=2 ;OverlayColourKey=0xf81f UseSysMemOverlay=0 OverlayColourKey=0 ;When TextureReplacement=1, the MemAddr section can be used to set the memory addresses ;to patch. The following executables are currently detected and memory patches applied: ;T2 v1.18 ;[MemAddr] ;CopyTex=0x41D948 ;MipMap=0x41D96B ;CreateVidTexture=0x62A67C ;TextureExists=0x5BD427 ;CreateFile=0x60015C ;BltPrimary=0x591440 ;TG v1.37 ;From Assidragon in this post: ;http://www.ttlg.com/forums/showthread.php?t=117616&p=1719806&viewfull=1#post1719806 ;[MemAddr] ;CopyTex=0x418BEE ;MipMap=0x418C11 ;CreateVidTexture=0x5DA9B4 ;TextureExists=0x576978 ;CreateFile=0x5B614C ;BltPrimary=0x548480 [PostProcessing] ;Enable=0 ;Include overlay in postprocessing. Boolean. Overlay=1 ;Modulation for the unbloomed frame buffer. 0xrrggbb. Base=0xffffff ;Saturation of the unbloomed frame buffer. 0-255. ;(255 = full saturation, 0 = pure grayscale.) BaseSaturation=192 ;Bloom intensity. 0-255. (0 = disable all bloom processing.) Bloom=255 ;Gain from bloom level to the next. 0xrrggbb. (0x404040 = zero gain.) BloomPersistence=0x404040 ;Bloom saturation. 0-255. (255 = full saturation, 0 = pure grayscale.) BloomSaturation=128 ;A per-level zoom-in factor. Integer. (0 = no spread.) ;This makes the bloom spread out (positive values) or in (negative values). BloomSpread=0 ;Colors below this will cause no bloom. 0xrrggbb. BloomThreshold=0x202020 ;Trailing and afterimages. 0xaarrggbb. (0 = no trailing.) ;The rgb components modulate the trail color, while the alpha component governs ;how much of the bloom from the last frame is blended into the current frame. BloomTrail=0x80ffffff [Fog] ;Enable fog. Boolean. Enable=1 ;Global fog. 0 = no, 1 = autodetect (requires TextureReplacement=1), 2 = force. Global=1

 

[AluminumHaste]

Try wrapping that ini post around

 tags instead of spoiler.

[Trickster]

Try wrapping that ini post around

 tags instead of spoiler.

sorry for that :-)

i figured it out,

i set [PostProcessing]

Enable=1

and it works. I do like heavy bloom in T1

[LEGION]

Now you´re more happy than me because I can´t get post processing to work in T1.

 

Oh, and with 'default' I meant the default-values. I felt they are too strong...

 

Could you please post a screenshot from Thief1 with Bloom, please? I´d like to see it only once...

Edited October 4, 2010 by LEGION

[Trickster]

sure i will

 

 

howewer, when i load Thief, image is overbright, while i play Calendra it´s fine

 

 

or, at least, a bit better

 

Edited October 5, 2010 by Trickster

[LEGION]

Hmm, sweet. Thanks for posting. You know how to decrease the size of the hud/lightgem, do you? (can´t stand that big hud...)

[Sotha]

[bloom images]

 

I always was a bit puzzled why people like bloom effects. Bloom effects enabled, ingame world looks the same as real life when you get some dirt or oil in your eyes. Fuzzy/cloudy...

 

A matter of taste, I suppose.

[New Horizon]

I always was a bit puzzled why people like bloom effects. Bloom effects enabled, ingame world looks the same as real life when you get some dirt or oil in your eyes. Fuzzy/cloudy...

 

A matter of taste, I suppose.

 

I really don't understand it myself. It's just one of those cinematic effects that have pushed their way into games in recent years. Personally, it does nothing for me...especially if it's as strong as in those pics. Although it does soften the old Dark Engine graphics a bit.

[nbohr1more]

The problem with many of the modern Bloom and HDR effects is that they are intended to be subtle enhancements that remove artifacts and make the scenes more accurate. The only way to have a dramatic effect with Bloom and HDR is to either 1) Have a lighting artist carefully paint dramatic lighting differences in the same scene (still pretty subtle) or 2) Go gonzo and exaggerate the effect until Bloom artifacts are visible. When marketing folks have trouble showing via extreme screen-shots the benefits of a new graphic technique, they choose the most crass hit-you-over-the-head options. So it has become trendy to abuse Bloom (it's the new Lens Flare). The same thing applies to some of the recent SSAO demos from ATI where the effect was exaggerated so badly that it looked like the objects had a hard outline. One of the worst outcomes is when an actual game has some of these bad decision built into the look, like the new Wolfenstein title where every objected is coated in specular highlighting.

[demagogue]

It's interesting to see, especially to see an old familiar place in a new light. You could say similar things about a black & white mod, or desaturated palette, or other visual effects; it makes you want to play again to see how things look. Bloom is interesting sometimes, especially when part of good artistic direction generally. What's bad about it IMO isn't so much the effect itself but the attitude when it's used, like you can literally feel it's about marketing suits pressuring games to have more "Poochy the Cool Dog" elements to wow fans but are really soulless. It's something you feel, not something inherent in the effect per se (unless it's just not done well, bad art design.)

[Melan]

It's interesting to see, especially to see an old familiar place in a new light. You could say similar things about a black & white mod, or desaturated palette, or other visual effects; it makes you want to play again to see how things look.

That's a good observation. Looking at those shots from Calendra, I am tempted to fire up Darkloader on my laptop and play a few missions. OTOH, "it's the new Lens Flare" also nails the problems with the way it is being used.

[stumpy]

cant see the point of bloom, the only time you can get the effect of bloom in real life is when you've drunk about seven pints (beer) and everythings gone swirly.

[Tels]

cant see the point of bloom, the only time you can get the effect of bloom in real life is when you've drunk about seven pints (beer) and everythings gone swirly.

 

If done *subtle*, it is nice to have. However, most of the games/videos I have seen just amount to the "eye drops effect", e.g. these drops that you get from your ophthalmologist when they want to see your eye background clearly. For a few hours after, looking at bright lights like a nice clouded sky, a car headlamp or even a white paper will make your head hurt

[Sotha]

these drops that you get from your ophthalmologist when they want to see your eye background clearly. For a few hours after, looking at bright lights like a nice clouded sky, a car headlamp or even a white paper will make your head hurt

 

Heh. I can confirm this. I had this done to me one month ago. I looked like a junkie, with my pupils expanded.

[LEGION]

Yeah, you have to be subtle. I thought against it as I read about it, but as I saw it in DarkMod the first time and decreased the effect I was stunned and don´t wanna miss it again.

 

Just compare these two shots: Okay, the bloom in the second shot is maybe a little too much, that´s because since I saw bloom in THIEF recently I doubled the effect...

 

without bloom:

 

with bloom:

 

I love this warm light-effect around, on the wall.

 

If used subtle it´s definitely a winner, isn´t it?

Edited October 7, 2010 by LEGION

[Sotha]

If used subtle it´s definitely a winner, isn´t it?

 

To answer directly to the question presented: somehow I still prefer the non-bloom shot. It looks more clear/crisp to me.

Sharp, not blurry.

 

Plus bloom probably has some kind of performance impact as well.

[SiyahParsomen]

I prefer none of them. I love pitch black.

[nbohr1more]

This weekend, I was playing TDS instead of working on my map (I know). It struck me how good the normalmaps looked - very clean and very deep. I wonder, did they do it with a normal generator, did they do it in Photoshop or did they go the whole way and make them based on 3d models.

 

 

 

I thought t# also used another form of height map, is it parralax? Not really a normal map but more like a 3d function where it brings out more depth. It's been awhile and I haven't payed much attention to it.

 

 

I've been thinking about these posts for awhile because I had just been reading the following thread about heigh maps at D3W:

 

http://www.doom3worl...&t=1154&start=0

 

This has brought me to the following questions:

 

1. Can a height map be used to amplify the precision of a normal map?

 

Process:

 

1) Create High Poly model (no ultra-fine details or wrinkles etc)

 

2) Create Low Poly model

 

3) Render a height map

 

4) Re-render the high poly model by reversing the height map

(only seen this done once and was a cumbersome process AFAIK...)

 

http://www.doom3world.org/phpbb2/viewtopic.php?t=23265

 

5) Create an Ultra High Poly model with wrinkles etc

 

6) Bake normals (normap map) from the Ultra-High to the re-rendered High poly

 

7) use the addnormals function to combine the normal map and height map and thus have all the normal map resolution dedicated to fine details while the height map has the coarse height variation (proper resolution hierarchy?)

 

xxx

 

2. Would that process really increase the available precision or are Normal Maps defined in an absolute scale in reference to the surface rather than a relative scale?

 

 

3. Since the process above is the opposite of what appears to be the intended usage, what about baking the ultra high poly model to the height map rather than using the height map for "hand drawn" displacements?

 

4. Is all this moot because addnormals degrades(?) normal map and height map quality?

Edited October 11, 2010 by nbohr1more

[rich_is_bored]

All images used in a bump map stage are compiled into a single 8 bit per channel normal map. No precision is gained by using additional maps that isn't lost once everything is internally reduced to a single normal map.

 

But color depth isn't really the issue. With 24 bit tangent space normal maps that's 256 red values, 256 green values, and 128 blue values. All together that's roughly 8 million possible angles that can be represented, all of which are relative to the polygon they are applied. Try to imagine a semi-sphere constructed from 8 million polygons and that's how accurate a 24 bit normal map can be.

 

In my opinion, the only reason you would have trouble capturing detail in a normal map is a lack of resolution. In other words, the pixels are too big relative to the details they are supposed to represent. If you increase the resolution you bake at, you'll get more detailed normal maps at the expense of video memory.

[nbohr1more]

Thanks for the clarifications Rich.

 

I think I have again used the wrong terminology somewhere but pixel density is one area that appears to be saved in the method I described as the height map would have all the coarse values saved to it allowing the normal map all the high resolution changes. I suspect, however, that DDS compression (at the very least) has it's own hierarchical resolution method so my concept is probably redundant.

 

I see that at one time they (id) were considering having "world space" normal maps but decided to postpone support for that method. Perhaps that is what is being used in TDS that has caught Melan's attention... (Not sure whether tangent space or world space is the default normal map format for Unreal engines...)?

Edited October 12, 2010 by nbohr1more

[rich_is_bored]

Tangent space normal maps represent a relative deformation to the surface normal of the underlying polygon. World space normal maps represent the absolute surface normal irrespective of the underlying polygon.

 

I've heard it said that world space normal maps are better but I'm not sure I believe that. The surface normal of a polygon is partly based on the position of each of it's points. And since those positions can be represented with decimal numbers while a color value can only be represented by whole numbers I can't see how a world space normal map could be more accurate.

 

But this is besides the point. The matter at hand is depth and normal maps do not simulate depth. They simulate slope. You're probably interested in parallax or relief mapping both of which use height maps. But I don't know if that's used in TDS to any extent.

 

Here's an example...

 

http://www.doom3world.org/phpbb2/viewtopic.php?f=56&t=23985

[nbohr1more]

Don't mind me Rich, I just have this superstition that the Unreal engines are doing "something" to improve Normal Map rendering over what Doom 3 has done. Maybe it's just the artists, maybe it's just the higher-poly assets but every time someone raves about Normal Maps in Unreal or TDS my superstition comes back. To make matters worse is UE3 has something called "Virtual Displacement Mapping" which most in the industry just claim is another name for Normal Mapping but I KNOW that can't be right.

 

After pondering further the only other thing I can think of is that the Normal Map renderer in Unreal does some further interpretation or correction of the underlying Vertex Normals. Maybe they create new Vertex Normals at run-time and thus make the Tangent Space normal maps look more like the World Space ones. Yeah POM or Tessellation are the ultimate surface detail techniques so this is probably a lot of useless wheel-spinning. It's just the implication of a "hidden factor" that bothers me (and there probably isn't one ).

Edited October 13, 2010 by nbohr1more

[SneaksieDave]

For the record, I tried out the pom mod and (like several others in the thread), didn't work for me either. Just normal, normal mapping.

[nbohr1more]

Did you load up Sikkpin's test map or were you trying this in the Doom 3 game?

 

(I think you need to add height maps to the alpha channel of the normal maps according to some comments...?)