HDR Issues and fixes (Log problems here)

#1 I'm having a problem with any of the postFX being there when I come back into a level. Do I have to save as a preset and reload the preset every time?
I came on today looking for some good information/ideas/techniques/tutorials for using the various postFX when I saw this post.

#2 When you edit the postFX settings in a level and then save them, it will want to create a postFX config script for that level. If it exists for any level while loading the engine will load those settings and apply them to postFX. So make your changes to the settings and save them. If you want to setup a global postFX then take the settings script and either include it after the postFX have been initialized or reconfigure the default postFX settings with the settings in that config script.. Phew, mouthful. In my current project (for right now) I'm just including the settings I want after postFX initialize. So that any level loaded gets these settings applied, but can alter them further from there. At least that's how it was working pre 3.0 MIT. I haven't actually checked in full on this on v3. I'll make sure to do so and report back if there are any issues.

#3 It looks like the problem was that it was saving my preset into the game/levels directory. I copied my preset to the core/scripts/client/postFX directory and then it worked when I went into the level....but, it was overlayed on top of default.postFXpreset.cs. So I just deleted everything in default.postFXpreset.cs and then it appeared as I had set it. I don't know if it's saving to game/levels by default or if that's something I did accidentally. If it's doing that by default then maybe it should be fixed. Also, it appears that the preset file has to be saved in the format LevelName.postfxpreset.cs

EDIT: I'm trying to create a preset for a 2nd level now with a different name and very different settings but it doesn't seem to be applying those settings when I go out and back into the 2nd level.
Still testing...

#4 Scot, you need it in game/levels mate. You also need to keep the postfx name the same as the level name.

#5 Dan's right. Let's take the level Empty Terrain.mis for example. When you save presets for this level w/ version 3.0. You'll end up creating a file called "Empty Terrain.postfxpreset.cs" and it should be located in the relative path game\levels. Which is where your mission file should also be located in the basic template.

As long as you stick to this method, you can create completely different postfx presets for every level and it should automatically load and apply them every time.

#6 I've kind of felt that the HDR in Torque probably needs a full rewrite for it to be really functional and of good use. The system feels somewhat convoluted for as little good effect that comes of it.

Not sure just how difficult some of it may end up being though. Tonemapping in particular. Something where you can have huge, near arbitrary light values for something that are properly factored in. Like the sun for instance, still the same solid white as everything else. But "brighter" in that when you look at it, everything else is heavily darkened by contrast.

But I guess for that to really work well all over would require a lot more than just a shader change.

#7 Oh, I wasn't eluding to just a shader change. I need it to actually function properly for my current project. Right now I'm just evaluating what the issues currently are with it, to get an idea of what's actually broken in the current and to see what either needs to be done or replaced / fixed. So lots of heavy testing for me right now.

#8 Two bits (in my opinion).... A major issue with T3D HDRI.... the 'sprites' that make up the sun image and any lens flair effects are not treated to the HDRI effect process. This is where a large number of the issues with the current HDRI come from.... Just a starting point for anyone that wants to take this on.

Oh yeah, one other thing, this is NOT a 'traditional' HDRI effect (you can't have true HDRI WITHOUT some sort of global illumination going on and Torque does not have any form og GI going on at the moment.) I would actually place this more in line with a 'bloom' high-bred' than HDRI. (to confirm, check out your 'specular' reflections to see what I am talking about. (If they 'glow', then it's bloom not HDRI).

Ron

#9 I completely agree with your assessment Ron. Though I was hoping I overlooked something. Though it's not to say that it's terrible either and I'm not bashing the current setup. The thing I do want to see is GI with indirect lighting. That would have a really substantial impact on the engine's "look".

I'm starting a GI Implementation right now. Once that's done, I was planning on attacking the HDRI but honestly, I think at least for our setup I'm going to replace it with a full HDRI setup instead.

#10 Smally, Any progress? I have made a bit but, I want to see what your research has produced. (on my side, I got GI working on a basic level, problem is I can not transition from one GI 'node' to another without a FPS/MSPF hit that is substantial).

Ron

#11 Not much, sorry bud. I just got out of the hospital today (been there the last week and a half). I've been back on the engine work here today finally since the drugs are no longer making me see triplets.

As far as GI Goes, I wrote a proof of concept program for myself here (before my trip to happy fun land) and it works great. Problem is, DX9 Can't handle it either, same issue. I've setup probes throughout the scene and update each one. With DX10 I can do this with a simple geometry shader and hit about 35 to 40 of these probes at a time. With DX9, basically forget it. Not happening. The best I've been able to come up with would be a cpu/gpu combo and do progressive updates. With fast movement though that falls apart. So I'm just not going to do that.

The next thing I was going to setup and go after is an implementation of reflective shadow maps. I think that's the best we could hope for.

Right away though, if dynamic light isn't required for the game, I'd like to see us go after a light baking solution for T3D. That would be plenty handy as it is. What are you thoughts?

#12

Quote:light baking solution for T3D

Why not just write a function which will export the level to some format Blender(and maybe other software) can import. Then you can bake lights there and import them to Torque.

I just googled a bit and it seems light baking using Cycles is not yet supported by Blender. Still i think my point still holds. It will be much better for Torque to start delegating certain functions to other established open-source projects, rather than trying to be all-in-one solution. Since clearly there is not enough willing developers to keep the engine up to date on all fronts.

#13 I like the GI solution as most up to date engines use some kind of GI solution. IMO, that would be a step in the right direction. I feel it should be worked into the lighting system maybe an option to turn it on and off. I would like to see the eye adaption to be worked in, when out doors the player would experience a blighter scene, then the eye would adapt, visa versa going indoors. Also maybe a 64 bit HDR pipeline is in order.

#14 HDR already has a 64-bit pipeline. It does currently select what it thinks is the "best" render format for your video card and system that can produce the effect. So, if your system can handle 64-bit textures, it will use that instead of using a 32bit int texture and "fake hdr" to get it done. The tone mapping and hdr settings also already does do eye adapation currently. You can find that under the PostFX Settings on the HDR tab. There will be a tab called "Brightness" and the slider is "Brightness Adapt Rate". That will allow you to control the speed at which the game will perform it's eye adaption.

@Taras, I'm not keen on writing solutions in which the 3d program doesn't have a solution for first anyway. I'd rather the engine do it, so you have some control there in the environment your working with but that's just me.

#15 smally,
I wasn't for sure about the 64-bit HDR and eye adaption. I see the options now, I guess I wasn't totally for sure how and what was going on but I can see it now!
Honestly the only thing I can see that needs to be done is the GI, but that's nothing the engine currently supports so it would be more of an addition.

#16 No worries.. I just hoped you were able to find them there.. Would be bad if you couldn't but the HDR does need work. Ron pointed out a good tell tale sign that shows the issue with the hdr rendering. It's not 100% but it won't be that hard to fix either.

#17 smally,

Sorry for the late reply, been working on a ton of stuff at the moment. I DID find moderate success.... however, there are limits. I can use a single 'large scale' global probe for outdoor areas (it's not 100% accurate but, unless you are REALLY looking for errors it works, this is actually VERY similar to CryEngine's solution, think 'approximation' versus 'accurate'). Problem is, we can't go from exterior to interior seemlessly. For interiors the only work around I have is to do a short 'loading screen' to cover the transition and relight the scene. Not a terrible idea but, gimps T3D a bit. Then again, if it works and is effective.....

See this is what I have been telling a number of people DX9c is NOT bad. In fact DX10 and 11 are REALLY just DX9c+, you can do the SAME stuff, just NOT as efficiently. This holds true for GI and even tesselation. (I have a simple tesselation shader as well.... but, again it's not ready for the public).

More to follow once I get back into it.

Ron

#18 Well, when pushing some algorithms, the geometry shader helps a lot. Just to push this off to the gpu, that's all. I don't believe dx9c is bad, hell if it's a comparison, dx10 and dx11 do, at times, render slower than dx9c. Which to me is meaningless to me anyway because for every situation there will always be a counter argument. Though one thing I do want is order independent transparency, as that just makes that whole bag a lot easier.

Just about all GI and most effects are approximations. I was just having some fun and went for it. I use to write a lot of raytracing code to render scenes in intel assembly, for a long time. It's just a different solution to the problem. Some drawbacks occur, but so do positives and it got my brain kick started back into graphics mode.

I'm amazed that people don't even remember ROAM for landscapes. Which was exactly dynamic tesselation for the terrain landscapes, even water or other models (if you were brave).. Hell we use to do that on a Voodoo.. Talk about primitive acceleration. Either way, it's even easier to do that now with multicores.

After I get a couple things here off my plate, I'll jump back into the GI area. I may have an idea or three on how to deal with the probe for the interior. I'm still just jumping back into the saddle still. So bear with me.

#19 No worries, I have a full plate as well. My FPS video shows off what I managed for interiors and I have not really had time to get back to it (though I did rework some of the exterior stuff). Your problem with transparency... more than likely has to do with the misconception that T3D does deferred rendering versus deferred lighting. I know we have a TON of references to Crytek engine tech in the core code but, this is a major difference between T3D and CryEngine. T3D uses deferred lighting, NOT deferred rendering.... This is why we can have 100s of lights in a scene and if they are properly placed we see no FPS or MSPF hit.... Anyway, I am getting a bit technical. Check it out when you get time. I think what we want can be done, it's just going to take a 'special case' solution to make it all work out. Oh and as a starting point for my solution... check this thread: www.garagegames.com/community/resources/view/21060 (Yep, I build a TON of stuff off of 1/2 solutions.... why reinvent the wheel?)

Ron

#20 lol. I get the difference. I'm actually not running into a problem with transparency at the moment, just looking at future thoughts while doing present tasks (fun right?). I'm more than certain it can be done as well btw. I'll check it out. I'm in cruise mode right now so no worries there. Funny that you would point that out in the link, as that was the implementation of SSAO I had been using for a while there.. Right now I'm working off of an almost stock T3D for the master server port, but the codebase for my project right now is heavily modified. I don't even dare mix the two.