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

[nbohr1more]

I admit I have gleaned my data from outside sources rather than reading the entire codebase myself.

 

With scripting intact, the picture is less dire. I read an interview where it was said that scripting was removed

as it was a big source of bugs in the original release. Perhaps they left it in but hard-coded every scripted event

in the game to ensure performance and stability.

 

That said, I was under the impression that BFG has no support for RoQ videos, and it is missing the native GUI system that TDM's

readables rely on (using Flash instead?).

 

Asset conversion? So someone would need to take our whole asset base and invoke some console command to convert it?

Not sure how tedious that might be. It would also add an additional burden for mappers. Still might not be too bad. This is probably the biggest

bugaboo. If anything remotely looks like it will break compatibility with old maps it will probably scare off any interest. Nobody is interested

in rebuilding old maps for a 3rd time now. If the conversion is flawless and relatively labor free then it's not so much of an obstacle.

Someone would need to "prove it" by demonstrating TDM on BFG.

 

I wont comment on the DLL \ EXE situation other than to say it's a familiar workflow so replacing it may encumber some inconvenience

to those few who currently code...

[HMart]

Motorsep to me it runs great with shadow maps for most of the time just some particular scenes add some slowdowns, i have AMD HD5770 in crossfire so that may be why it runs well.

 

You seem to know much about the BFG engine, so if you don't mind can you give me some enlightment, i tried to play a custom test map, made on Dark Radiant using custom textures, but BFG refused to play it, the console sees the map but when i use the command "map mylevel" i just see a black screen with no sounds or movement, i did dmapped it using the vanilla engine and put the materials and the textures on the BFG base folder, i would love to play with this engine and make some test levels and import some of my models but the vanilla doom 3 way of doing don't seem to work right away.

[motorsep]

@HMart: Shadow maps, the way they are implemented now, are good for Doom 3 BFG vanilla, and for GPUs with 256bit VRAM.

 

People who can play BFG with their 64bit VRAM crappy GPUs, can't really play it with shadow maps. It's irrelevant for RBDoom 3 BFG really, because you can switch back and forth between types of shadows. But if you are planning on using engine for an indie game, I'd think twice using shadow maps.

 

Neither Doom 3 BFG GPL, nor RBDoom 3 BFG can't be easily used for modding. There is a lot of stuff not working right or broken. We are at the point where engine is fixed up to the point of being usable to build games from scratch. Dmap is in, all tools are in (all working except GUI Editor, but that's in progress), a lot of rendering issues/bugs fixed, some renderer's enhancement have been made, etc.

 

That being said - patience - once alpha of my game is out, the engine will be out too, along with dev portal. Then you can either use it for TDM, or any other game, or mod my game

[7318]

you can play your own maps in BFG if you create your own mod folder and place all your assets needed for this map outside a pk4 in the mod folder.

pk4 support shouldn't be that difficult to reintroduce though. I haven't look at it though.

 

mod creation wise, BFG is regular d3 sans pk4 and full-screen GUI (although the game still uses GUIs for in-game in-surfaces GUIs).

I've looked into the GUIs issue and the code for the full-screen GUIS seems to be not that complex, and the references to full-screen GUIS are the same as in regular D3 except they have replaced with the flash calls, One thing I want to reintroduce is full-screen GUIs by adding them besides the flash calls, so if you have a flash file for that GUI you're served with flash (so you can retain BFG functionality, and I know Motorsep has done some flash GUIs for his own game )but if you miss the Flash content you can use *.gui files. (which is the idea here)

 

for full-screen GUIs menus there is a new thing that needs to be introduced in the GUI code though, keyboard/gamepad GUI navigation.

[7318]

on the shadows and on the modular architecture that Motorsep you commented about. modular architecture can reside besides specially crafted meshes/brushes, so it shouldn't be considered as a step back (specially when instancing could be used for other things than map's architecture) architecture wise can help to render huge cities as modular architecture can be used in conjunction to form several variations easily.

 

on shadow maps, really? do you really see using small lights to recreate the shadows casted for every alpha-masked grass bush on the map viable?

 

but shadow maps implementations shouldn't be regarded for the "benefits" of the mapping aspect of the technique, but because it also incorporates the possibility to alter those shadows via GLSL, so even if the jittered shadows currently kill the computer performance if you have a lower end card (in my case are completely off because I'm using mesa, but my laptop is not going to last forever ) the potential for the future improvement outweighs whatever one can do with stencil buffer shadows.

[motorsep]

mod creation wise, BFG is regular d3 sans pk4 and full-screen GUI (although the game still uses GUIs for in-game in-surfaces GUIs).

 

Not only. Fonts are different, the way you write scripts is slightly different, game code is slightly different, shaders are different.

 

I've looked into the GUIs issue and the code for the full-screen GUIS seems to be not that complex, and the references to full-screen GUIS are the same as in regular D3 except they have replaced with the flash calls, One thing I want to reintroduce is full-screen GUIs by adding them besides the flash calls, so if you have a flash file for that GUI you're served with flash (so you can retain BFG functionality, and I know Motorsep has done some flash GUIs for his own game )but if you miss the Flash content you can use *.gui files. (which is the idea here)

 

On the contrary, I wanted to add Flash to interactive surfaces, so that designer can use either However it's not easy, especially to have both working at the same time.

[motorsep]

modular architecture can reside besides specially crafted meshes/brushes, so it shouldn't be considered as a step back (specially when instancing could be used for other things than map's architecture) architecture wise can help to render huge cities as modular architecture can be used in conjunction to form several variations easily.

 

Or you can make entire buildings as unique models and performance will be the same, except that you don't need OpenGL 4.x (needs that for instancing) and you don't need to engineer more code.

 

on shadow maps, really? do you really see using small lights to recreate the shadows casted for every alpha-masked grass bush on the map viable?

 

Sure, why not? Alternatively you can make grates as geometry, and since shadows cast from those will be precomputed, performance drop won't be significant. For a field of grass, if you really need grass to cast shadows, then use 1 projected light per grass patch.

 

Another important thing to mention is that if you have shadow mapping shadows from alpha tested surfaces, and majority of your users will run it with shadow volumes, they won't see those shadows. So if you don't care for people with decent, but less powerful GPUs, go for shadow mapping.

 

My reasons to use shadow maps vs shadow volumes, considering performance differences are minimal (or shadow mapping is much faster, like in Darkplaces/Tesseract engines for example), are following:

 

- Use of complex geometry (the more polys models have, then more polys shadows will have, the more cost at calculating silhouette; not the case with shadow maps)

- Implementation of Forward+ rendering (can't implement that with shadow volumes; although it will require OpenGL 4.x)

 

Since RbDoom3 shadow maps perform horribly, and forward+ rendering requires OpenGL 4.x, I temporarily gave up on shadow maps.

 

but shadow maps implementations shouldn't be regarded for the "benefits" of the mapping aspect of the technique, but because it also incorporates the possibility to alter those shadows via GLSL, so even if the jittered shadows currently kill the computer performance if you have a lower end card (in my case are completely off because I'm using mesa, but my laptop is not going to last forever ) the potential for the future improvement outweighs whatever one can do with stencil buffer shadows.

 

All features require practical approach. You gotta ask yourself what is the benefit of adding these features. How is shadow mapping, for example, going to help your game succeed? In this particular case it only will make Phoronix drool over it and remains of Doom 3 community say "cool". That's all there is for this particular implementation.

 

A rule of thumb is to implement features you need today. When tomorrow comes, and you still need new features, implement those tomorrow. That's what efficient development is about. Not making perfect engine suitable for all game types and all features, forever (unless you are in the business of making and selling game engines).

 

So when you are making a game, you want to make a _game_. Shadow mapping won't make Doom 3 any better game than it is now. But slow shadow mapping will make people, who otherwise enjoyed the game, cringe. With this sluggish world economy, chances are high for the current hardware distribution to stay at about the same level in the next 2 years. So you will still have about the same ratio of people with 256bit GPUs to 64bit GPUs (referring to VRAM here).

 

To summarize, I am not saying "throw away shadow mapping". I am saying: "Make fast and scalable shadow mapping". Fast shadow mapping should look decent and be as fast as shadow volumes. Pretty shadow mapping should look much better than shadow volumes, but not drop performance to the ground.

[7318]

on the GUI vs Flash.

why do you say it's not easy to have both working at the same time? you only check if you have the flash resource and if you do you load it, if not then load the *.gui asset, or error.

 

on the Shadow Mapping.

instead of wasting the entities on lights for the effect and waste cycles with several lights you just use a single light entity and light the whole area correctly.

 

on added implementation.

I would say that the elements that need to be there in order to develop for BFG to me are:

maptools ( dmap/testmap/aas )

bring back debug modes with colors

GUI

pk4

 

do you happen to know what has changed scripting-wise? and material shader wise?

c++ code wise all is mixed in the d3xp code.

[motorsep]

on the GUI vs Flash.

why do you say it's not easy to have both working at the same time? you only check if you have the flash resource and if you do you load it, if not then load the *.gui asset, or error.

 

Because we looked into it. Fullscreen old gui rendering is not entirely in the BFG's code. You would need to port some stuff over from idTech 4. And 2 systems can not co-exist. I was explained by the programmer who was looking into it, but forgot the details. Either way, if you think it's easy, then by all means implement it and show it to us

 

on the Shadow Mapping.

instead of wasting the entities on lights for the effect and waste cycles with several lights you just use a single light entity and light the whole area correctly.

 

You can have 8192 entities per level. That's plenty. You can even extend it more (requires deeper changes, but doable). You still waste computation power to shadow mapping. It's not free by any means. It's more about CPU/GPU vs VRAM bandwidth, and bandwidth is not cheap. That's why 256bit GPUs cost arm and a leg, and 64bit GPUs are dirt cheap.

 

...

GUI

pk4

 

If you are modding Doom 3, why do you care for menu? People aren't gonna play menu, they will be playing the game

Pk4 is obsolete packaging. New .resources have all tools in the engine to author it for distribution.

 

c++ code wise all is mixed in the d3xp code.

 

Not quite. It's a bit different for certain things (which I don't know how to explain, since I am not a programmer). Some code, such as vehicles for example, was not directly portable and we had to rewrite code to accommodate for new code base.

[SeriousToni]

Nice to see we have very experienced coding people here on these forums who can also do a polite discussion (though I don't understand anything )! *thumbs up*

[Sotha]

Nice to see we have very experienced coding people here on these forums who can also do a polite discussion (though I don't understand anything )! *thumbs up*

 

Yes, I love it how people are civil around here! It truly is something unique.

 

It is a pity I do not have the expertise to estimate how much the Project "BFG soft shadows to TDM" would have progressed if all the energy used in the discussion was focused on the project instead.

5%? 10%? 50%? Sadly, we will never know...

[7318]

I care about FS GUI because modding is the first step to creating one's game. hence why I care about menu.

 

explain how pk4 is old packaging? do you intend to sell your game in a console, if not, why is it then old packaging? also, what about sharing assets amongst other members of the community? pk4 is a neat way of sharing small mods that are useful for other members of the community, as a resource for mod making, in my case the portalsky stuff. I could pack all the resources in the pk4 quite easily, how do I use the *.resource file? and what is the benefit of having all the content from a level all packed up in a single file, other than quickly loading a map assets on consoles.

Edited May 21, 2014 by 7318

[motorsep]

Nice to see we have very experienced coding people here on these forums who can also do a polite discussion (though I don't understand anything )! *thumbs up*

 

Thanks, but I am not a programmer 7318 is.

[motorsep]

I care about FS GUI because modding is the first step to creating one's game. hence why I care about menu.

 

Use Flash

 

explain how pk4 is old packaging? do you intend to sell your game in a console, if not, why is it then old packaging? also, what about sharing assets amongst other members of the community? pk4 is a neat way of sharing small mods that are useful for other members of the community, as a resource for mod making, in my case the portalsky stuff. I could pack all the resources in the pk4 quite easily, how do I use the *.resource file? and what is the benefit of having all the content from a level all packed up in a single file, other than quickly loading a map assets on consoles.

 

pk4 is slower vfs than .resources for all I know, without getting into too much details. while on PC difference in read/search speed in .resources isn't not huge over pk4, on Android devices you will literally feel/see the difference (and eventually I am hopping to bring Storm Engine 2 to Android / iOS). Again, if pk4 is so easy to bring back, why hasn't it been done so far?

 

In BFG, you can't use .resources for mods, even for main game packaging because it's designed for DVD distribution for consoles. We modified it to act as pk4, where you don't have packaging per map, and you can author .resources for a mod, and run it with +set fs_game <modFolder> where mode folder contains single .resources file with content of your mod.

[SeriousToni]

Thanks, but I am not a programmer 7318 is.

 

Oh, but you surely talk like one!

[7318]

I'm no programmer.

Who is "we" ? are you talking about Robert Beckebans?

 

on the GUI.

how does the flash implementation work?

as far as I know the GUI for menus are the same as the GUIs on models only that they display on top of the rendered image (while they pause the rendering of anything else) so you would only need to recreate this action.

I searched the dhewm3 code and the BFG code that loaded the loading screen for the maps and found the line that is replaced for the flash call. so from there one would get to the actual class that do the work and then should be copy and paste from Dhewm3 to BFG. only that in BFG since we have already the flash implementation you would only check if there is already a flash file that does it, and if it does exist you would use the flash implementation, so you could still use flash for menus and HUDs and other full screen GUIs while the rest of us are free to choose which one we want to use. it's the best of both worlds.

 

Now I'm battling with the modding of BFG, I've done some maps and successfully loaded them onto BFG (just test box maps, and test textures), I've tried to incorporate a new weapon I did for dhewm3, the model loads (I can testmodel it without any problem) but I can't seem to replace the shotgun with it. soon I'll try to incorporate the GUIs onto the BFG. it's not that I don't try, it's just that I haven't started on it yet.

 

on the resources, and the binary formats of BFG.

Is there a way to create the binary formats? if so, maybe we could try to add the process to the Blender importer/exporter?

even maybe we could incorporate the pk4 for the ease of development, and have a command to compile it all in a resource file for distribution?

Edited May 21, 2014 by 7318

[motorsep]

I'm no programmer.

Who is "we" ? are you talking about Robert Beckebans?

 

No, not RB. My team and I is who I refer as "we".

 

Fullscreen GUI is flawed. Someone (I forgot his nick on d3w) talked about it before d3w went down. It was taxing performance (hud in particular as menus/PDA didn't matter) like crazy. Flash has no such issue afaik. Also, Flash is a standardized tool that far more people know how to work with (graphically and Actionscript 2) than with GUI scripts. Not to mention superb animation support.

 

I wish we had Flash for interactive surfaces already, to keep it consistent with fullscreen interface, and flexible.

[7318]

I was me back at d3w who was insistent on it, because I had added the "wheel of pain" of modern shooters in d3

tell me, what do you use to author your flash for the HUD and PDA that you already showed in one of your videos in alpha stage?

 

with Actionscript can you create objects and repeat it "n" times? this can't be achieved with d3 GUIs.

 

Flash for interactive surfaces shouldn't be that difficult to include in the game code also.

Edited May 21, 2014 by 7318

[motorsep]

I was me back at d3w who was insistent on it, because I had added the "wheel of pain" of modern shooters in d3

tell me, what do you use to author your flash for the HUD and PDA that you already showed in one of your videos in alpha stage?

 

with Actionscript can you create objects and repeat it "n" times? this can't be achieved with d3 GUIs.

 

Flash for interactive surfaces shouldn't be that difficult to include in the game code also.

 

I use Flash MX2004. It's kinda crappy (crashes a lot) but does the job. I might upgrade to CS5.5 if they still sell it on Amazon (or might just go with subscription for CS6, once I have menu art ready).

 

Action script is fully fledged programming language, so to speak. You can do Matrix-like screen of falling letters I am not sure what you mean about repeating object. If you create it by coding it, then yes perhaps.

 

Oh, and you can make wheel of pain in Flash too.

[7318]

I don''t have to if I could implement GUI back to BFG.

[HMart]

you can play your own maps in BFG if you create your own mod folder and place all your assets needed for this map outside a pk4 in the mod folder.

 

Don't know what i did wrong but that didn't worked.

 

The steps

 

Made a folder mymod in the BFG root outside of base, inside i put all the assets for the map with the same naming convention of vanilla doom3, maps, textures, materials, sounds, etc. Made a .bat file to launch the mod using "Doom3BFG.exe +set fs_game mymod +set fs_basegame mymod +set developer 1 +set com_allowconsole 1 +set r_fullscreen 1", when ingame used the console command map mymap but nothing it starts the loading process but quits to main menu without any error on the console or anything.

 

To Motorsep how do you create the .resources package? I know of the console command but the console help for it is not very helpful.

[motorsep]

Why is this +set fs_basegame mymod there? No need for that.

[7318]

have you complied your map in another engine? if not, you have to compile your map in another engine and then copy the resultant map files ( *.cm, *.map, *.proc ) into your maps folder.

 

don't use the original "Doom3BFG.exe" download the last of the releases of RBDoom3BFG (in the first post of this thread)

[lowenz]

Excuse me but.....anyone can recap me about ALL RBDoom3BFG features? Thanks!

Edited May 22, 2014 by lowenz

[motorsep]

Excuse me but.....anyone can recap me about ALL RBDoom3BFG features? Thanks!

 

https://github.com/RobertBeckebans/RBDOOM-3-BFG/blob/master/README.txt