BFG with shadow mapping perfect for trees and other alpha masked planes

[7318]

take a look at the screens below in this link:

 

https://github.com/R...-3-BFG/releases

Edited May 19, 2014 by 7318

[AluminumHaste]

That is awesome.

[Springheel]

Soft shadows would definitely be nice to have, but it's a lot of work.

[New Horizon]

Indeed. It's questionable as to whether or not the soft shadow implementation from D3 BFG edition would even work in our standard idtech 4 based engine.

[nbohr1more]

The guy who made this is the only developer who has successfully ported the BFG renderer to vanilla Doom 3.

 

Even without soft shadows, such a feat would be an immense improvement.

 

If we want this tech we should find some way to appeal to Robert for assistance...

[Obsttorte]

The BFG code makes use of shaders written in OpenGl shader language, which would be the first thing we would have to add support for, unless we are aiming for translating all those shader progrs into ARB assembly.

 

Another point would be to identify which parts of our code are actually dealing with shadow generation, so we know what to replace. I don't know what actually changed in the core renderer compared to vanilla doom3, but if it's quiet a lot I'm not sure if Robert Beckebans would like to do the work again even if pose codes are relatively similar. But asking never hurts, though.

 

What is really impressive to me is the shadow casting of alpha-tested decals. We have quiet a couple of them and it definetely adds something, although we can currently fake that effect (custom light textures).

 

Let's see.

[New Horizon]

It's possible he would be willing to answer any questions and act as a guide.

[Obsttorte]

True. This would really be of help.

[nbohr1more]

Does anyone know what we should get this dude for X-mas?

 

Hooker? A gold plated Lionel train-set? The best Imperial Stout in Europe?

 

[lowenz]

If we want this tech we should find some way to appeal to Robert for assistance...

Join the Dark Si.....Mod

Edited May 20, 2014 by lowenz

[motorsep]

The guy who made this is the only developer who has successfully ported the BFG renderer to vanilla Doom 3.

 

He didn't port BFG renderer into idtech 4. That shadow mapping stuff is in modified BFG fork.

[nbohr1more]

He didn't port BFG renderer into idtech 4. That shadow mapping stuff is in modified BFG fork.

 

He has stated in previous threads at Doom3world that he has ported the renderer but he wont release that work since it's incorporated

in an in-progress commercial project. He was thinking about perhaps offering the source as an early access bonus for his indiegogo project.

 

He also made a pre-light renderer for vanilla doom 3 that performed on-par with BFG but he abandoned that approach. He was also planning

on releasing that code too... eventually.

[Obsttorte]

It's already up:

 

https://github.com/RobertBeckebans/RBDOOM-3-BFG

[nbohr1more]

No that's BFG based. We are referring to vanilla Doom 3 for which these render fixes have not been made public.

 

The closest we have is RaynorPat's "morpheus" project which has BFG's GLSL renderer and some of it's VBO code.

[7318]

BFG is way more than just GLSL. the biggest thing with BFG is the multi-threaded renderer. already with stencil buffer shadows it's quite fast. the cascaded shadow maps it's a must if there are long vistas and huge open cities a la Assasin's Creed. And it seems the author is quite engaged with the project at the moment.

 

I think, but I'm not 100% sure, that there is some kind of instancing in the BFG renderer. which makes render the same model multiple times way speedy than before.

at least my tests on my crappy computer showed no sign of slowdown when rendering a complex model with stencil shadows several times, (if I did the same with the last great port of the engine, dhewm3, this would have chocked the engine)

[Obsttorte]

No that's BFG based. We are referring to vanilla Doom 3 for which these render fixes have not been made public.

 

The closest we have is RaynorPat's "morpheus" project which has BFG's GLSL renderer and some of it's VBO code.

BFG is based on vanilla, so parts of the code are similar and bfg stuff could also be ported to the vanilla respectively TDM source code.

[motorsep]

He has stated in previous threads at Doom3world that he has ported the renderer but he wont release that work since it's incorporated

in an in-progress commercial project. He was thinking about perhaps offering the source as an early access bonus for his indiegogo project.

 

He also made a pre-light renderer for vanilla doom 3 that performed on-par with BFG but he abandoned that approach. He was also planning

on releasing that code too... eventually.

 

Stating is one thing, showing it off is another. He showed off features for BFG fork only

 

Vanilla Doom 3 engine will never perform on par with BFG, regardless of what you do to the render. I also tested BFG with shadow maps, and performance is worse by far than with shadow volumes. So people with Intel GPUs, average AMD/Nvidia can forget about shadow maps.

[motorsep]

BFG is based on vanilla, so parts of the code are similar and bfg stuff could also be ported to the vanilla respectively TDM source code.

 

BFG is based on idtech 5 (rendering, input, networking, threading, sound). Game code and framework is from idtech 4.

[motorsep]

BFG is way more than just GLSL. the biggest thing with BFG is the multi-threaded renderer. already with stencil buffer shadows it's quite fast. the cascaded shadow maps it's a must if there are long vistas and huge open cities a la Assasin's Creed. And it seems the author is quite engaged with the project at the moment.

 

I think shadow volumes would still work for that. It's just sharp, not soft

 

I really wanted shadow mapping, but after testing RBDoom3, I am kinda reserved now.

 

I think, but I'm not 100% sure, that there is some kind of instancing in the BFG renderer. which makes render the same model multiple times way speedy than before. at least my tests on my crappy computer showed no sign of slowdown when rendering a complex model with stencil shadows several times, (if I did the same with the last great port of the engine, dhewm3, this would have chocked the engine)

 

There is no instancing in BFG. Afaik instancing is OpenGL 4.x feature and only benefits rendering of static geometry. Modular architecture, like one seen in UT3/Gears of war, would benefit. Unique level design won't.

[motorsep]

Btw, speaking on the subject, tree shadows can be made with projected lights

[SeriousToni]

I don't understand much of this but soft shadows would rule so hard...!!!

Edited May 20, 2014 by SeriousToni

[nbohr1more]

BFG is based on vanilla, so parts of the code are similar and bfg stuff could also be ported to the vanilla respectively TDM source code.

 

Yes, there are some similarities. BFG is a hybrid of Tech 4 and Tech 5 and they obviously didn't start completely from scratch. Too bad we can't see

the interim steps that Id Software went through to merge the projects. Since RaynorPat has this merge\porting work partly done, it might not be too

long before someone else finishes the work... it's just a little frustrating to know the work is done but behind locked doors...

[motorsep]

I don't see the benefit back porting BFG into idTech 4. Can someone clarify the benefit?

[nbohr1more]

1) No need to convert art assets, textures, sounds, video

2) No need to port game SDK code

3) No need to port code from gamex86.dll to the executable ... BFG doesn't support DLL loading

(though the benefit of not needed to manage memory between the exe and DLL might outweigh that)

 

One thing I thought I read is that BFG doesn't support scripting. TDM uses scripts...

 

Some of these are less of an issue for TDM than other projects that have not merged their SDK code with

the executable.

[motorsep]

Sounds like someone has no clue about BFG engine :/

 

1) No need to convert art assets, textures, sounds, video

 

You don't need to convert anything. BFG engine will do it for you.

 

2) No need to port game SDK code

 

I am pretty sure it less work than it sounds. There are minor differences between 2 game code bases. It will take time, since DarkMod is huge.

 

3) No need to port code from gamex86.dll to the executable ... BFG doesn't support DLL loading

(though the benefit of not needed to manage memory between the exe and DLL might outweigh that)

 

Have you ever looked into the code? It's exactly the same thing. Just instead of EXE and DLL after compiling, you get EXE + DLL, monolith builds. It's easier to debug than with DLL btw.

 

One thing I thought I read is that BFG doesn't support scripting. TDM uses scripts...

 

Yes, it does support scripting. And scripts from Doom 3 match up scripts from BFG 99.9%.

 

I don't know you came to all these conclusions.