Revelation Test

[Spiney]

Isn't the sliding simply how pixel offset mapping works? Cannot "extrude outwards" so need to "extrude inwards" ... = sliding pixels relative to surface.

[revelator]

Its indeed how its explained but then why does this one work ?.
Sikkpin had several versions also one with offset limiting which is imo the one that works best but it still had the sliding textures problem just not so much.
The one i dug up resembles that one visually but without the sliding.
Maybe a hack ? in case it is its quite good

[revelator]

Code: Select all

!!ARBvp1.0 OPTION ARB_position_invariant ;

TEMP	R0, R1, R2;
PARAM	defaultTexCoord = { 0, 0.5, 0, 1 };
SUB		R0, program.env[4], vertex.position;
DP3		result.texcoord[0].x, vertex.attrib[9], R0;
DP3		result.texcoord[0].y, vertex.attrib[10], R0;
DP3		result.texcoord[0].z, vertex.attrib[11], R0;
MOV		result.texcoord[1], defaultTexCoord;
DP4		result.texcoord[1].x, vertex.attrib[8], program.env[10];
DP4		result.texcoord[1].y, vertex.attrib[8], program.env[11];
MOV		result.texcoord[2], defaultTexCoord;
DP4		result.texcoord[2].x, vertex.position, program.env[9];
DP4		result.texcoord[3].x, vertex.position, program.env[6];
DP4		result.texcoord[3].y, vertex.position, program.env[7];
DP4		result.texcoord[3].w, vertex.position, program.env[8];
MOV		result.texcoord[4], defaultTexCoord;
DP4		result.texcoord[4].x, vertex.attrib[8], program.env[12];
DP4		result.texcoord[4].y, vertex.attrib[8], program.env[13];
MOV		result.texcoord[5], defaultTexCoord;
DP4		result.texcoord[5].x, vertex.attrib[8], program.env[14];
DP4		result.texcoord[5].y, vertex.attrib[8], program.env[15];
SUB		R0, program.env[4], vertex.position;
DP3		R1, R0, R0;
RSQ		R1, R1.x;
MUL		R0, R0, R1.x;
SUB		R1, program.env[5], vertex.position;
DP3		R2, R1, R1;
RSQ		R2, R2.x;
MUL		R1, R1, R2.x;
ADD		R0, R0, R1;
DP3		result.texcoord[6].x, vertex.attrib[9], R0;
DP3		result.texcoord[6].y, vertex.attrib[10], R0;
DP3		result.texcoord[6].z, vertex.attrib[11], R0;
SUB		R1, program.env[5], vertex.position;
DP3		result.texcoord[7].x, vertex.attrib[9], R1;
DP3		result.texcoord[7].y, vertex.attrib[10], R1;
DP3		result.texcoord[7].z, vertex.attrib[11], R1;
MOV		result.texcoord[7].w, 1.0;
MAD		result.color, vertex.color, program.env[16], program.env[17];

END

#======================================================================

!!ARBfp1.0
OPTION ARB_precision_hint_nicest;

TEMP	light, color, R1, R2, localNormal, specular, eye, height, newtexcoord, newbumpcoord, newspeccoord, newspeclook;
PARAM	subOne = { -1, -1, -1, -1 };
PARAM	scaleTwo = { 2, 2, 2, 2 };
DP3		R1, fragment.texcoord[7], fragment.texcoord[7];
RSQ		R1, R1.x;
MUL		eye, fragment.texcoord[7], R1;
TEX		height, fragment.texcoord[1], texture[1], 2D;
MAD		height.x, height.z, -0.05, 0.05;
MAD		newbumpcoord, height.xxxx, eye, fragment.texcoord[1];
MAD		newtexcoord, height.xxxx, eye, fragment.texcoord[4];
MAD		newspeccoord, height.xxxx, eye, fragment.texcoord[5];
MAD		newspeclook, height.xxxx, eye, fragment.texcoord[6];
DP3		specular, newspeclook,newspeclook;
RSQ		specular, specular.x;
MUL		specular, specular.x, newspeclook;
DP3		light, fragment.texcoord[0],fragment.texcoord[0];
RSQ		light, light.x;
MUL		light, light.x, fragment.texcoord[0];
TEX		localNormal, newbumpcoord, texture[1], 2D;
MOV		localNormal.x, localNormal.a;
MOV		localNormal.z, 0.99;
MAD		localNormal, localNormal, scaleTwo, subOne;
DP3		light, light, localNormal;
TXP	R1, fragment.texcoord[3], texture[3], 2D;
MUL		light, light, R1;
TXP	R1, fragment.texcoord[2], texture[2], 2D;
MUL		light, light, R1;
TEX	R1, newtexcoord, texture[4], 2D;
MUL		color, R1, program.env[0];
DP3		specular, specular, localNormal;
TEX	R1, specular, texture[6], 2D;
MUL	R1, R1, program.env[1];
TEX	R2, newspeccoord, texture[5], 2D;
ADD	R2, R2, R2;
MAD		color, R1, R2, color;
MUL		color, light, color;

PARAM 	darken = {0.9,0.9,0.9, 1};
MUL		color, color, darken;
MUL		result.color.xyz, color, fragment.color;

END

this is it btw, if someone can spot something usefull feel free to use.

[leileilol]

.. you can write ARB shaders!? I wish I could. Assembly scares me and I'd like to bring my 3DFX filter to shader model 1.4 someday.

[revelator]

Wish i could but sadly that one's not by me i think its based on guy named junkguy's work though.
Might be handy for those who want a working parallax shader in doom3 though.

[Dr. Shadowborg]

Recently reinstalled Doom3 and decided to try this.

"(null) is not a valid win32 application"



Somebody needs to tell the guys who couldn't obsolete WinXP support in the compile tools fast enough that they SUCK, and SUCK BADLY.

[leileilol]

Ironically DefectiveByDesign is applied to try and convince people to switch to Linux. ahh gnu...........

[qbism]

TDM-gcc supports XP, as well as VS.

[revelator]

I can compile a version for XP with msvc 2012
I should remember to do that every time theres a new release anyway just keep forgetting heh.

Btw i been toying with using the dmap shadow occlusion code actively instead of only while using dmap and it has some interresting results.
Objects greater than about 20 will slow down the engine to a crawl (1 fps) so i capped it at 20 and it works pretty fine for removing shadow artifacts from maps with that problem.
Quite scary to read its output actually there seems to be quite a bunch of degenerate triangles and non visible lights on small objects and with the level of detail this port is capable off its become rather annoyingly visible.

[revelator]

If someone is skilled with MFC code i could use a hand fixing up radiant + tools.
The PDA editor needs to be finished and there are a number of things in the other editors that need fixing.

[nbohr1more]

If someone is skilled with MFC code i could use a hand fixing up radiant + tools.
The PDA editor needs to be finished and there are a number of things in the other editors that need fixing.

Have you pinged Greebo, Taaaki, Orbweaver, or Grayman over at The Dark Mod forums?

I know Greebo is working on a wxWidgets port of Dark Radiant, perhaps you can replace some of your code with
that.

In addition, one of our dormant coders, Serpentine is usually on the freenode IRC channel #thedarkmod.

Finally, you could also try pinging Sparkhawk, stgatilov, or Crispy (old TDM coders who rarely visit the forums)
or ping Bikerdude who might be able to get you in touch with Tels ( Tels is a disgruntled former TDM coder...).

Oh, you could also post over at:

http://idtechforums.fuzzylogicinc.com/

which is sorta a reborn version of Doom3world.org

[revelator]

Thanks m8 ill start pinging

Ive also looked into converting the BFG engine into something suitable for vanilla like vanillas pk4 support / vanillas gui / and using vanillas texture renderer etc.
it might be doable but it will be a huge project, one man has little hope of doing this by himself unless he or she is a code guru (which im not).
It might be worth it though as that would net us a modern Doom3 engine with the nessesary tools allready built in (especially if we can port the MFC bits to a crossplatform library).

Best approach might actually be taking the BFG engine and slowly work in the parts needed for it to work with vanilla. Robert Beckebans port might be a nice starting point

[toneddu2000]

you should ask motorsep. Steel Storm engine 2 had the exact task: converting all BFG engine features and tools to Doom3 vanilla code. And, for what I understood, he succeded!

[revelator]

If he wants to share the code that would be nice would also benefit his work i think if we can move the tools from vanilla to the BFG engine and make them crossplatform.

[toneddu2000]

well, I don't think he would, but at least he should have all the knowledge to help you out. He's been always so kind to reply to all my bothering questions! Infact, as you stated earlier, this could be a daunting task to perform on your own, nonetheless I think you're really good at programming (I've seen how many times you helped me out!) !