TDM Engine Development Page

[SteveL]

Excellent, thanks. But I haven't even gotten round to reading up on it yet, just back from visiting friends. What's a quick way for me to test it so you don't have to wait for me to commit it?

 

I'll spend this week experimenting with particles to try to find a general rule for them, then on to other stuff.

[nbohr1more]

Well, the quick way would be to make use a small test map with one light and replace that light with a cubmap light

and replace the interaction.vfp with the shader I posted or the one in the cubmap demo.

 

Then you could see what the projection behavior looks like without building a new executable. If you wanna take it further

and fix the vfp with all of our specific interaction changes, then that would be cool too.

 

Example material:

 

lights/cubelightCube
{	
{
	forceHighQuality
	   cubeMap		lights/lightCube
	colored
	zeroClamp
}
}

 

after compiling a new exe:

 

lights/cubelightCube
{	
cubicLight
{
	forceHighQuality
	   cubeMap		lights/lightCube
	colored
	zeroClamp
}
}

 

Created tracker 0003881

Edited October 19, 2014 by nbohr1more

[nbohr1more]

OK, this is a bit of a hack job but I believe I've merged the cubemap projection into the default interaction.

cubic_light.vfp.txt

[nbohr1more]

Heh, an ARB based GPU skinning shader. Will look for more:

 

http://sourceforge.n...SkinProgram.arb

 

another...

 

http://www.nvidia.com/docs/IO/8228/GDC2003_OGL_ARBVertexProgram.pdf

Edited October 20, 2014 by nbohr1more

[motorsep]

Not quite sure why do you want cubemap lights, they are slow like any other IBL solution.

[SteveL]

Heh, an ARB based GPU skinning shader. Will look for more: http://sourceforge.net/p/bhmfileformat/svn/HEAD/tree/trunk/BHM3DSample/Data/VertexSkinProgram.arb

 

Sounds good but I wonder how much work that'd be to implement? It looks fairly straightforward, although you'd have to set the uniform constants differently for each model by the look of it, as they're used to pass the joint positions. I take it we do this on the cpu then?

 

I'm going to have to keep all these leads bookmarked...

[nbohr1more]

Yes, vanilla Id Tech 4 does this on the CPU. I was just tickled that you could do this in ARB and then I went back and saw that

GPU skinning was practically the whole point of the Vertex Shader specification and Doom 3 uses almost no vertex shader operations?

 

(I'm guessing Carmack was battling with buggy OpenGL drivers for too long to trust shaders for this...)

[motorsep]

From what I know (as we attempted this right before migrating to BFG) GPU skinning can not be done using ARB assembly.

[HMart]

Not quite sure why do you want cubemap lights, they are slow like any other IBL solution.

 

They aren't that slower, and cubemap lights can be used to do more then lighting a scene, even tho that is the primary reason to have them, but they can also be used to simulate shadows (and colored shadows if necessary) that need to be casted 360º around the player, like a static point light inside a cage in the middle of a room and also be used to improve ambient lighting, having the option to use them is better then not.

[motorsep]

They aren't that slower, and cubemap lights can be used to do more then lighting a scene, even tho that is the primary reason to have them, but they can also be used to simulate shadows (and colored shadows if necessary) that need to be casted 360º around the player, like a static point light inside a cage in the middle of a room and also be used to improve ambient lighting, having the option to use them is better then not.

 

Image based lighting rendering is slow is what I am saying. I know what it is and how it works Just saying it's slow. You'll feel the performance hit if you implement it and use it. Not to mention you need to implement blending between local probes. Generation of those probes/cubemaps happens at turtle speed. You can try it already - doom 3 had ambient map generation cmd.

[revelator]

maybe this can shed some light on it (phun intended)

 

http://docs.unity3d.ru/Components/class-Light.html

 

not directly related to Doom3 but theres some good pointers in there for how to cope with the performance loss.

[Guest garthzombie]

Hey guys,

 

How come you guys don't go on over to BFG edition (at least RB-BFG edition with shadow mapping) feels like a nice base to use and GLSL is pretty handy to have if you want to do anything modern.

 

I am not saying you should, just want to understand why not

 

Thanks!

[motorsep]

Hey guys,

 

How come you guys don't go on over to BFG edition (at least RB-BFG edition with shadow mapping) feels like a nice base to use and GLSL is pretty handy to have if you want to do anything modern.

 

I am not saying you should, just want to understand why not

 

Thanks!

 

Besides shadow mapping being poorly implemented (on top of few other things), redoing all GUIs in Flash and porting game code is a massive undertaking for TDM team. Plus I bet Light Gem would have to be rewritten.

[nbohr1more]

The main reason, our architect Greebo has (mostly) retired from coding and we have yet to see another coder who understands our frameworks

and infrastructure well enough to do it.

 

The secondary reason is that porting the GUI code to "something new" would be a big pain.

 

The tertiary issue is we would have to rebuild the resource loader to match our "Fan Mission" loader system.

[revelator]

Was explained earlier in this thread, but to sum it up (it would at its current state be to much work to port all the changes made to darkmod's source to a new engine).

 

btw i just stumbled upon something, it seems gpu skinning is actually possible with ARB assembly, its just not very well documented so hard to find any examples on how to do it.

 

gpu skinning requires gpu matrix operations which have been part of OpenGL since 2000 so yes it can be done, but it will take some experimentation since theres nearly no documentation on it.

 

reason theres no documentation seems to be that by the time where GPU's actually had the muscle to do it people had pretty much switched to GLSL so noone ever made an attempt at documenting it.

Edited October 20, 2014 by revelator

[nbohr1more]

I'm thinking, on a high level overview, GPU skinning could be added to the existing interaction and shadow vfp shaders but

we'd need to find where the verts are passed to the CPU for skinning (which I think the Intel pdf outlines, time to re-read).

 

We'd need a branch there and another akin to the trick for creating a new light type.

 

It might be useful to first narrow the scope to shadow generation and try to backport BFG's shadow skinning shader from GLSL to ARB

just to see how or if we can get it to work. If we get any performance benefit from just shadow skinning, then all the better.

[AluminumHaste]

Hey nbohr1more, keep an eye out for the delivery man.

[Tels]

Was explained earlier in this thread, but to sum it up (it would at its current state be to much work to port all the changes made to darkmod's source to a new engine).

 

btw i just stumbled upon something, it seems gpu skinning is actually possible with ARB assembly, its just not very well documented so hard to find any examples on how to do it.

 

Sorry for interrrupting, but wasn't there talk that ARB is to be phased out sooner or later, anyway? Why would we spent the time to bring GPU skinning to it, only to have to throw that away soone or later?

[nbohr1more]

Most of this is a learning exercise to get familiar with the current renderer and augment along the way where possible.

Adding a GLSL backend is a big code addition and would probably also require fixing existing material assets too.

Plus, it's fun to see how much you can squeeze from an archaic graphic API?

[Tels]

Most of this is a learning exercise to get familiar with the current renderer and augment along the way where possible.

Adding a GLSL backend is a big code addition and would probably also require fixing existing material assets too.

Plus, it's fun to see how much you can squeeze from an archaic graphic API?

 

I don't mind the excercise, just wanted to caution that spending a lot of time with ARB might be better spent on the migration to GLSL - not that I could judge how much "too much" is, of course

[Guest garthzombie]

Fair enough I think that's a justified answer.

 

Motorsep, what's your problem? Do you enjoy bashing peoples work? I think Treb did a pretty decent job at adding shadow mapping, and you just calling it poor is really unprofessional.

[SteveL]

We're in no major hurry for glsl I judge. I don't think we'd suddenly get lots more shader programmers on board, and we have no immediate plans to invest a lot of time in new shaders. And to answer my own question from a few pages ago, no, glsl would *not* give us truly branching code, not the kind that'd allow different execution paths in the same draw anyway. That turns out to be very undesirable from a hardware perspective. If anyone did announce end of support, that'd provide the motivation of course, but it's doubtful that it'll happen. People still use it and customers want to play old games. The other motivator would be if we wanted to use some cool toy only available in shader model 3+

[motorsep]

Motorsep, what's your problem? Do you enjoy bashing peoples work? I think Treb did a pretty decent job at adding shadow mapping, and you just calling it poor is really unprofessional.

 

I am just speaking the truth. Not bashing anyone. I profiled RBDoom 3, approached Treb several times, pointed out where the problems are (performance wise). He is either too proud or doesn't care. I also found massive slow down that is present when shadow mapping is on, but couldn't report it as he blocked me out of his repo. So I asked someone else to report it. Same thing - he doesn't care. We also began implementing shadow mapping in our engine, using Treb's code as base. Found a lot of problematic design and such, went out of our way and reported it to him, providing better solutions. He rejected everything as he just doesn't care.

 

If you haven't noticed, I am not liking when a small group of people makes something that is sub-par and then all members start patting each other on the back saying "oh wow, good job, you are so awesome.. blah blah" instead of admit there are pitfalls and it still needs improvement, and potentially accept advise of more experienced software developers (not me, but someone who has been helping us). So just like you personally told quite a few people that their work on level design isn't great, or if they shouldn't do what they have been doing and they need to adjust their workflow, and no one came back at you saying: "Garthzombie/Zombie13, what's your problem? Do you enjoy bashing peoples work?" I expect you not to pop up on various forum and try shutting me up when I bring to attention pitfalls/problems of the tech that someone else, who didn't do the homework, trying to make look like God's given gift that surpasses wildest expectation in the performance and feature set.

 

You might see it as personal attack, as you have always looked a it, but all I am doing it pointing out areas where improvement should be made obviously. So what looks unprofessional is when you don't know the underlying tech, and the inner workings, and probably have state of art PC where you don't notice much of the issues, and then come back saying "I _think_ it's decent job". While people with average gaming PC and higher quality content than Doom 3 (TDM, if blindly ported to RBDoom 3) will have same performance issues they have now with old tech. And the problem is that there is no work around for it when using RBDoom 3. Can't have shadow mesh, can't turn of shadows, etc.

Edited October 20, 2014 by motorsep

[revelator]

I somehow doubt that the khronos group would throw away support for ARB assembly,

they still support the old opengl 1.1 standard but yeah its becoming a bitch to keep compatibility, so i can be wrong but lets see.

At some point GLSL will have to be worked in regardless, in case of new coders who are used to working with it and go ??? when someone says ARB assembly

I dont think babystepping it moving to a newer ABI is a bad thing i broke most of my first tries at fixing vanilla's shortcommings,

and it took up a huge amount of time moving the working parts to a new codebase so id rather take it slow from here and make sure i did not break anything before going further.

I do plan to get crafty with a GLSL backend based on what i could glean from the BFG source, it might even go hand in hand with the old arb2 backend to keep compatibility.

Atm the most complete non BFG based GLSL backend can be found in https://github.com/omcfadde/dante

unfortunatly it uses GLES so a few parts need to be ported and mc fadden is dead so the project is stalled :S.

Also all non BFG GLSL backends are missing the function to interact with vanillas material shaders,

so we need to construct a parser that is able to read out GLSL info from the materials, BFG should give some clues as to how though.

Im going to look over how to achive this soon but atm im bedridden with a somewhat nasty flu so it might take a few days before i can report anything.

[revelator]

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.