TDM Engine Development Page

[motorsep]

p.s. Msep i hope to report back soon on a posibility to turn of the math for shadow generating completely.

 

Thanks, we actually nailed it last week (almost). So no worries and thanks for trying. Actually as it turned out it wasn't about turning off math, it was about feeding shadow job "finished" state. This way it was done before ever starting Massive CPU performance gain that can be used by physics/AI.

[SteveL]

@revelator: Ack, hope you get well soon!

 

Any help you can give us on the path to updating our openGL use will be fantastic and very much appreciated. I'm looking forward to using GLSL one day. In the post above I'm just staking out my position as to why it won't be one of the next 2-3 things I work on

 

Do you think that updating some of our openGL calls and (in particular) using FBOs instead of our old buffers will speed up capturing the buffers to a usable texture? Testers have found that using the new depth capture function costs 2fps in spots where fps is already depressed. That's not too high a price for the benefits, but we do a lot of those captures. 3-4 per frame, not counting depth capture.

[Guest garthzombie]

Msep is just vocal about his beliefs i can respect that critisism is a helpfull tool in hunting down buggers you might have missed,

allbeit it sometimes comes out badly especially when written (hard to gauge a persons intent via text sometimes).

 

P.s Msep i hope to report back soon on a posibility to turn of the math for shadow generating completely.

 

Problem with that guy is that he isn't constructive, and in a community of modders you can't talk like that, it begins to generate a negative atmosphere.

 

Saying someone did a poor job in public against someone who's trying to do something for the community is just bad taste.

 

If he worded like: It's a good implementation, but it could use a little bit of improvement to make it better, that's a constructive comment.

 

But I have him on ignore he's not worth time time.

[revelator]

Thanks steve newer ABI should allmost allways give a performance improvement = (more functions move from CPU to GPU).

GPU's are much faster in handling those kinda calls then a CPU cause thats there primary function.

 

@Msep no worries but im glad you got it sorted out i bet some here might want to hear more about the modifications so if you got time to pop up a tutorial sometimes i think it will be appeciated.

[motorsep]

If he worded like: It's a good implementation, but it could use a little bit of improvement to make it better, that's a constructive comment.

 

That's a kiss a$$ comment. It's a decent implementation, but needs _a lot_ of improvement. Now this reflects the true nature of things with shadow mapping in RBDoom 3 BFG.

 

But I have him on ignore he's not worth time time.

 

Good for you.

 

Note, that I don't have hard feeling against Treb. He is a bright developer, one of the very few who understands rendering part of idTech 4 / BFG. However, then way he does things... It's like RBDoom 3 is his portfolio, no major changes accepted from outside especially to features that could potentially help landing a job gig.

Edited October 20, 2014 by motorsep

[revelator]

Well if you knew how many times i was misinterpreted for writing stuff to help others out...,

sometime they took it as an attack on there pride as coders, other times they wanted me to finish up there work for them.

which would not help them next time they ran into a problem (im not online 24/7) also im not paid to do there homework but mostly i help where i can.

I cant even say i was free of those flaws myself, because i sometime made a huge effort to get something to work, but the code was a mess i still felt hurt when someone pointed it out.

At a point i began to look at things differently because even if my code was flawed it did sometimes solve something that the experienced programmers had tried to work out and the experienced programmers could then clean up my work and make something truely usefull out of it.

So they where happy and even though my initial work was a mess i had contributed something.

As for my pride i can only say its not my daily work (im educated as a radio technician) i do this for fun and learning and i have and still am learning.

[nbohr1more]

Someone very generous gifted Prey to me and I took a peek. The materials have "blend program" functions but the lights do not have the ability to call their own vfp shaders the way that Sikkpin's feedback demo can. Also, it seems Sikk may have changed his mind about including "blend program" possibly to distinguish his work from Human Head's. Pretty interesting, there's a bunch of what I'd call legacy Doom 3 materials and vfp code for hardware too old to run Prey. It's very much like a high-end Doom 3 mod with the same pak structure etc. Going back to feedback for a moment, Sikk did something there that irks me a bit... He changed the order of the stage inputs so now you can't compare his feedback ARB to Doom 3 ARB without translating the input numbers.... Grr. I guess his loading order makes more sense but its a shame that can't be used as out-of-box as a learning tool.

[revelator]

Ah was worth a try.

Now that you have it you should play it its a refreshing game and quite a bit insane hehe.

The story is not bad either, its so far out it makes it allmost sound plausible that something like that could have happened.

 

Takes a bit to get used to the gravity differences and running topside down though.

[nbohr1more]

Still might be useful for asset testing... I'll make a map if you've got a compile of feedback?

 

I might be able to work out the missing bits...

 

I'm almost regretting the hard-coded way I setup the light shader branch. It seems feedback can just grab the vfp name

from the material shader itself so that might be a better approach anyway. I can always add another branch that behaves

that way though.

[revelator]

Still bed ridden but ill make a compile as soon as im able to sit in front of my PC for more than a few minutes again.

[nbohr1more]

Yeah, sorry about your health these days. Watch those late night coding sprees, you'll blow what's left of your immune system.

[revelator]

Heh thanks allthough atm i think im getting more than my fair share of sleep.

Flu is all over denmark because of humid cold weather just got unlucky and caught some

[nbohr1more]

OK, this is probably old news, but the Ashli viewer can automate GLSL to ARB conversion:

 

http://developer.amd.com/tools-and-sdks/archive/legacy-cpu-gpu-tools/ashli-advanced-shading-language-interface/

 

this functionality probably exists elsewhere but I thought I would post here for reference sake.

[revelator]

nvidia's parser should also be able to convert GLSL to ARB its not seamless though so the shaders will most likely need some work after conversion, still its a great tool

[nbohr1more]

Yeah, I just wanted to throw BFG's shadow_skinned.vertex program in and see if the ARB output looks comparable to other examples. I also see there's a reference to shadow_skinned.vfp in the BFG source... Is that something hidden in those funky .resource pack files? I guess I'll probably have to get BFG for Xmas because nobody savy enough to hang out in gaming boards would have bought it knowing that mods don't work. (Unless they were psychic and could've predicted the second source release ). OK motorstep, wanna post the code from shadow_skinned.vfp to help settle the wager about what ARB can\can't do?

[motorsep]

Yeah, I just wanted to throw BFG's shadow_skinned.vertex program in and see if the ARB output looks comparable to other examples. I also see there's a reference to shadow_skinned.vfp in the BFG source... Is that something hidden in those funky .resource pack files? I guess I'll probably have to get BFG for Xmas because nobody savy enough to hang out in gaming boards would have bought it knowing that mods don't work. (Unless they were psychic and could've predicted the second source release ). OK motorstep, wanna post the code from shadow_skinned.vfp to help settle the wager about what ARB can\can't do?

 

BFG only uses .vfp extension in the materials. It doesn't matter at all. None of the .vfp shaders are used by the renderer. My guess is that those were made at the beginning of the development. If you kill off all the shaders, and leave only Cg ones, BFG will compile GLSL shaders and run just fine.

Edited October 24, 2014 by motorsep

[revelator]

I think the old ARB shader in BFG was the one that was missing from vanilla, for the draw_exp.cpp shadowmap renderer.

Checking and yep its that one .

 

BFG does not use ARB at all only CG or GLSL so as motorsep said if theres only the CG files left it will convert those to GLSL, it cannot convert them to ARB as far as i can see.

[motorsep]

Btw, engine guys should really take a look at the results of profiling TDM here: http://forums.thedar...740#entry356740

Edited October 24, 2014 by motorsep

[SteveL]

I've done some more experiments on the water shader fix this afternoon.

 

I mentioned in the posts above that the quick fix blocked any distortion if the distorted color sample would be taken from the foreground. That fixed the distortion of foreground objects, but it left a clear area ("missing water") around the foreground object. It didn't matter very much in the video because I used a sandy floor (not deliberately) but it occurred to me that a tiled floor close to the water surface might make the gaps obvious. You can see that in this first pic, where there are undistorted tiles around the blackjack.

 

 

It also shows up around the edges of the water. You can see it in this second shot. The "new" water is on the right, old is on the left. The "new" water has missing blobs where previously it would have dragged in colour from the bits of wall in the foreground.

 

 

I've tried a few different fixes. As I promised last week, I tried selectively blocking the distortion from individual colour channels. That didn't help. It turns out the sample locations are only slightly different for each colour channel, so most pixels that were left undistorted in the first attempt stayed undistorted.

 

Here's my best attempt so far: in this version, when a water sample would come from a foreground object, instead of dragging in foreground colour or being blocked from distorting entirely, the shader reverses the direction of the distortion and takes a sample from the other side, mirroring the distortion if you like. It's not perfect, but then the heat haze shader was never meant to be studied up close

 

 

On consideration, that would also risk picking up artifacts from other nearby occluders.

 

It does do that, but I've tried waving various objects in front of it and it doesn't look too bad. The only time the effect was really noticeable was with moveable antlers. They are brightly coloured and branching. We could block that happening with yet another depth test, but I don't want to make the shader too heavy unnecessarily.

 

 

If anyone has any better ideas I can try, please chip in! I haven't done much research on this I admit, I'm just experimenting.

 

I'll upload the test map to svn so the team can see what they think. If anyone else wants to help test, I can provide a patched 2.02 TheDarkMod.exe (to enable depth capture), plus the .pk4 for the test map. Aside from the depth capture itself everything is done in the pk4 through shaders and shaderprogs, so there'd be no reason not to go on using the patched engine, but if you did want to revert your engine to the original build I think all you'd have to do is run TDM Update.

[Springheel]

Seems awfully good to me.

[SteveL]

Thanks. I've committed "Water fix test map".

 

I also threw in a portable depth window

[Arcturus]

The fix is great, but you've added dispersion, which in my opinion is too strong.

[SteveL]

The fix is great, but you've added dispersion, which in my opinion is too strong.

Could you unpack that a bit for me? I looked up dispersion on wikipedia but it's a bit too technical. I didn't alter anything consciously except what I stated above -- trying to find an alternative colour for what would have been distorted foreground. Is the problem a side-effect of the fix attempt do you think?

 

EDIT: If it was the extra coloured blobs on the water surface that you were looking at, they weren't due to the fix. The right-hand picture is busier because I accidentally used a smaller texture scale which makes the distortion more violent. I adjusted that before committing the test map.

Edited October 25, 2014 by SteveL

[Arcturus]

There's that iridescence as if RGB channels drifted apart. There was no such effect before.

[SteveL]

Ah. I'm pretty sure that's not new, honest It's always been in heathazewithmask (used by water_stream in the test map). It uses a separate distortion for the three channels. It's much more noticeable in my pics than usual because I've put the water under strong lights and used a small texture scale so the water is "moving" more violently than usual. You can see it on the left half of image 2 too, which is the unmodified shader.

 

I can try removing the effect from the shader if you want to see what it looks like without it. But it doesn't look so bad in the actual test map where the water's moving, and it'd be less noticeable still in a real map where the light will be a lot less bright. I did everything I could in that test map to emphasize the ugliness and visibility because I was trying to get snapshots of the glitches. And I lit the scene using opposing orange and blue parallel lights, which probably makes it worse still.

 

Edit: is there a particular water shader I should try fixing? I chose water_stream pretty much at random, but if you have another water shader in mind that has the same foreground distortion problem, I'd like to try that too.