Brtech1

[BeRo]

I've wrote a Quake3/idtech3-compatible engine (in most all things except API-wise, so it's not API-compatible) in the last month ago.

It's written in ObjectPascal completely from scratch (compilable with Delphi and FreePascal for many targets including Windows, Linux, MacOSX, Android and iOS). The engine is fully compatible with the Quake3 file formats, but it doesn't use the OpenGL fixed pipeline, instead it uses a 100% complete plain GLSL-based render pipeline (which's fully OpenGL ES >= 2.0 and Desktop OpenGL >= 3.0 compatible), where the rendering architecture is a mix between forward rendering (for to be Quake3-render-concept-compatible) and deferred lighting a ka light pre-pass for future feature extensions.

All geometric data (maps and models) are stored in static VBOs, so all vertexdeformations/textureanimations/etc. are calculated directly only on the GPU itself (including autosprite/autosprite2 deformations!), so the CPU has nothing to do in this context, except to do the PVS+FrustumCulling.

At MD3 models with vertex animations, all frames are stored in the same static VBO, where the vertex attribute pointers are pointing to different start vertex index positions, aPosition+aNormal+... for the the source interpolation frame and aPosition2+aNormal2+... for the target interpolation frame including a uInterpolation uniform float variable to interpolate between them directly on the GPU per GLSL vertex shader.

IQM model support is planned ( http://lee.fov120.com/iqm/ ).

The whole sound system is also self-implemented, which's based on my own old sound code stuff from the FoembJump Android framework.

Test binary: http://rootserver.rosseaux.net/stuff/BRTECH1.zip but you do need the original Quake3 (demo or full version) data for it, because the BRTECH1.exe binary searchs for the baseq3 (or baseoa if you have only OpenArena) subdirectory with the .pk3 files. But a small warning for OpenArena maps, it seems for me that, these are compiled wih a buggy q3map/q3map2 map compiler version => Z-Fighting on curved patch brushes. But on the original Quake3 maps this problem doesn't exist.

I'm searching for artists (quake3 mappers, quake3 material-shader-writers, quake3 texture-artists and quake3 MD3/IQM modellers) now for to doing the first real own demonstration indie game with it. If you do know someone for so such job things, then contact me please :)

And now some videos (P.S. door logics aren't implemented yet, so I've disabled the collisions with doors):


http://youtu.be/AlxogR9okdA


http://youtu.be/4YsrHI4bg58

BeRo

[Vinzvega]

Hi Benjamin,

wow, Very impressive ! And the implementation of the vertex manipulation and textures stuff on the gpu might be very cool ! It is the case for all the platform (ios ?) ?
Let us know the advance of your project on it !
- I'm not aware of quacke like stuff : is there some editor to use ?
- Have you a licence plan for this engine ? :)

cheers !
:)

[de_jean_7777]

Wow, this is amazing. I work (kind of still am) on an engine which also provides support for Q3 assests (maps, models and such), but I guess you beat me to it :D
Great work. I'm interested to see what kind of a game you might develop with this.

[paul_nicholls]

Wow Benjamin...just wow :D
I'm awestruck mate, kudos!!

[BeRo]

Hi Benjamin,

wow, Very impressive ! And the implementation of the vertex manipulation and textures stuff on the gpu might be very cool ! It is the case for all the platform (ios ?) ?


If the PowerVR SGX GPU in the iPhones supports at least 13 shader vertex attributes (because for the on-the-GPU-interpolation of animated models), then yes, because the OpenGL ES 2.0 specification says just 8 vertex shader attributes as minimum, but most all current mobile GPUs (PowerVR SGX 540, Mali400MP, Tegra2&3, Arendo205, etc.) in android devices are supporting at least 16 vertex shader attributes. But for example the OpenGL 2.0 capable GPU in the Raspberry PI is a OpenGL 2.0 capable GPU with the absolute minimum OpenGL ES 2.0 specification data (so only 8 vertex shader attributes as minimum etc.).


Let us know the advance of your project on it !
- I'm not aware of quacke like stuff : is there some editor to use ?
- Have you a licence plan for this engine ? :)

cheers !
:)
For maps: GTKradiant http://icculus.org/gtkradiant/ but only with the GPL full-opensource variant (where commerical usage isn't a problem, at least here in germany), because the old proprietary half-opensource/half-closedsource variant disallows commerical usage without a license from id Software.

For models: Blender, 3DSMax, etc. the models must be exported and converted then to the MD3 or the newer IQM file format.

License plan: I want to do myself a own game with it, before I'll start licensing with a unity-like freeimum model (here including a opensource dual license model, so the engine source code will be available under a dual-commerical-license-suitable opensource license, like idtech1-idtech4), so for free games => no cost, and for non-free games => small revenue participation (20% to 30%) and no high one-off payment in advance, so the planned licensing will mostly complete risk-free for the licensees.


Wow, this is amazing. I work (kind of still am) on an engine which also provides support for Q3 assests (maps, models and such), but I guess you beat me to it :D
Great work. I'm interested to see what kind of a game you might develop with this.
Thanks :)

As said, I want to do a game with it. A futuristic cyberpunk first person shooter or something in that game genre direction, but I do need still artists for this (for game detail concept design, maps, models, textures and material shaders). Code, SFX and music I'm doing myself. So i am looking for artists.


Wow Benjamin...just wow :D
I'm awestruck mate, kudos!!
Also thanks :)

[phibermon]

Excellent! :D I'm so happy to see another well developed engine surfacing, keep up the good work!

I also support IQM and IQE in JenJin, blender users looking for an animated 3D format should give it a go, the IQE exporter is well maintained across blender versions.

[BeRo]

Now with improved virtual-3D stereo sound engine code und underwater (physics, sounds and post process screen effect).

The whole sound engine code is bigger than the main renderer core code now.

The sound engine do support true 3D sound spatialization now (including ear-distance-delays, listener-to-object-angle-and-distance-frequency-filtering, etc.) and I'm working on full HRTF support as a additional high-quality-3D-sound-spatialization-work-mode.

The underwater sound filter effect is a 4-semitones-down-pitchshifter (without FFT/IFFT, very-short-delayline-based with a hamming fade window functon, only circa 20 code lines only), 300 Hz 6dB one pole low pass filter, 500-1000Hz boosting 3-band quadpole 24dB EQ and reverb.

It supports also the doppler effect now (air and underwater).

The most all sound engine code is 32bit integer-only (16.12 bit fixedpoint with 4 bit headroom, so it is 20.12 bit at the end) except at the initialization code parts for lookup tables, float -> fixedpoint constant value calculations, etc.

And here the new video. And the BRTECH1.zip at the URL in my start post in this thread is also updated.


http://www.youtube.com/watch?v=RBLErYWmSu8

[de_jean_7777]

Wow, you sure have put a lot of effort into your sound engine, though I guess this is expected from you :D

[phibermon]

That's utterly awesome, you really know your stuff!

[AirPas]

this is awesome , how's the engine code is it procedural (which is expected) or OOP

[BeRo]

this is awesome , how's the engine code is it procedural (which is expected) or OOP

The utils functions (math, system-related helper functions, and so on) are procedural and the engine core itself is fully object-oriented class-based. So it's circa 90% OOP and 10% procedural.

[Rodrigo Robles]

Great work, congratulations!

[Cybermonkey]

Absolutely stunning! Keep up that great work!

[Ñuño Martínez]

Good job. Really impressive.

May be I can drop-off Open Arena from my system soon. ;)

[BeRo]

So new BRTECH1.zip is online ( http://rootserver.rosseaux.net/stuff/BRTECH1.zip ).

BRTECH1 has HRTF support now, so BRTECH1 has following 3D audio spatialization modes now:


Fast fake 3D stereo (what the original idTech3 Quake3 engine also do, but still better than when 3D audio spatialization is inactive, so it's more a alternative for really slow CPUs :D )
Pseudo 3D acoustics (already very good pseudo 3D sound over stereo, but it is not so good like HRTF, so it's more a alternative for non-headphone users and/or slower CPUs)
HRTF (really very good und even true 3D sound over stereo, but only wih headphones, because this is the limiting factor of HRTF)


The mode is selectable with the spat(ialization) in-engine console command game, and it will be active for the next loaded map then.

And the whole sound engine code is still mostly 20.12-bit-fixed-point 32-bit-integer-only.

So have fun with it :)

[pitfiend]

May I ask where you get pascal headers for SDL 2.0? Are they Delphi compatible?

[BeRo]

May I ask where you get pascal headers for SDL 2.0? Are they Delphi compatible?

I made them for me myself (for statically and dynamically linking, since SDL 2.0 allows linking statically now), originally for my c64 emulator project http://micro64.de/. But I will keep these private until the SDL 2.0 API will be frozen. The problem at SDL 2.0 is that the API including data structures) are still changing, because SDL 2.0 has no stable release version yet.

[BeRo]

New BRTECH1 Engine while-in-development-demostration video. This time with most full map entity logic, player models and a third-person-view as an optional alternative for the first-person-view mode.

The next todo-steps will be: LiSPSM shadow mapping, networking, weapon shot physics, game menu UI, and such other things.


http://www.youtube.com/watch?v=U6KZl6VqnL8

[AirPas]

good progression , just the player speed , i found it a bit fast

[BeRo]

good progression , just the player speed , i found it a bit fast

I'm using just the original quake 3 player physics constant values, because I'm testing my engine with quake 3 maps. :)

[BeRo]

Again new BRTECH1 Engine while-in-development-demostration video

It uses Uniform Shadow Maps (USM, if one player is in current view) and Extended Perspective Shadow Maps (XPSM, if more than one players are in current view) together with Variance Shadow Mapping (VSM) and only with one shadow map FBO texture since it's targeted for mobile devices with limited video RAM size also, where Cascaded Shadow Mapping (CSM) wouldn't be applicable here.

And the first person is attached to the approximately eye position of the each head MD3 model part of the each current loaded player model now.

The next todo-steps will be: Networking, weapon shot physics, game menu UI, and such other things.


http://www.youtube.com/watch?v=iXWQ8OgsOjI

[SesillaAndromeda]

Hi Bero,

your engine will be available for us? Which type of licensing?

Thanks

[farcodev]

very good work, keep it up! ;)

[BeRo]

Yet again new BRTECH1 preview tech demo videos :)

It has support for external lightmaps, deluxemaps and for some DarkPlaces shader extensions now, for features just as bump mapping, offset parallax mapping, relief mapping, glow, bloom, and so on.

It has also an DDS texture loader now (with own DXT*-to-RGBA-decoder), because Xonotic maps are using mostly DDS textures.

Xonotic map red-planet:

http://www.youtube.com/watch?v=nubjG-3Nrpg

Xonotic map drain:

http://www.youtube.com/watch?v=XLscohdw3X4

Xonotic map afterslime:

http://www.youtube.com/watch?v=Sa_9cwVnKd8

[paul_nicholls]

Nice mate :)

[BeRo]

New public build: http://rootserver.rosseaux.net/stuff/BRTECH1.zip

This build is optimized for automatic-quakelive-data-detection, so it detects the quakelive data path automatically. So you do need only registered at quakelive and downloaded the quakelive browser plugin together with the encrypted game data, which this build will detect automatically and decrypt on-the-fly while loading in the RAM, for to can to test my 3D game engine BRTECH1 with legal game data.

Tthe first person camera handling is also improved. It includes a image stabilization for too fast wired moves now, it's mainly for the run/walk player model animations.

Keys:

f8 = toggle console
alt+enter = toggle fullscreen
t = toggle 1st/3rd person view
r = respawn
l = toggle wireframe
b = toggle bloom
etc.

and attention, quakelive seems to have some another physics constants than the original quake3, so player jumps in some quakelive maps "can be" sometimes too short.

[paul_nicholls]

Very nice work Benjamin...awesome as always :)

[BeRo]

Yet again new BRTECH1 preview tech demo video :)

The here new model lighting implementation is based on light-grid-voxel-based per pixel lighting on the GPU with a OpenGL 3D texture with light ambient color, light diffuse color and light direction normal (X&Y in each texel alpha channel, Z will reconstructed inside the GLSL shader code) per two RGBA8 texels/voxels.

It loads QuakeLive maps directly from the original app data data path of the legal-installed QuakeLive browser plugin installation on-the-fly for private engine-development-test purposes.

QuakeLive map toxicity:

http://www.youtube.com/watch?v=Dw_sYxaERn8

[phibermon]

looking awesome as usual! what are your plans for BRTECH2? have you looked at supporting doom3 / quake4 maps? I'm guessing they're still a BSP structure in principal. I think you have to support LWO models or somthing (can't remember exactly what I read)

[BeRo]

looking awesome as usual! what are your plans for BRTECH2? have you looked at supporting doom3 / quake4 maps? I'm guessing they're still a BSP structure in principal. I think you have to support LWO models or somthing (can't remember exactly what I read)

BRTECH1 does support the most visual features from idtech4 already, since BRTECH1 can load already (Darkplaces-Engine-based) Nexuiz/Xonotic Maps with deluxe maps (see http://www.youtube.com/watch?v=nubjG-3Nrpg http://www.youtube.com/watch?v=Sa_9cwVnKd8 and http://www.youtube.com/watch?v=XLscohdw3X4 ), with extended material shader definitions for bump mapping, parallax mapping and relief mapping and with other known-from-idtech4 features.

And BRTECH2 will be maybe totally different then, but I'm not sure here yet.

[Rodrigo Robles]

Man, it's really impressive!

[BeRo]

First test of the new yet slightly buggy light-pre-pass (a ka deferred lighting) render implementation including deferred shadowing. The GBuffer layout is at the moment:

RT0 (RGBA8): r=normal-spheremap-x g=normal-spheremap-y ba=specularpower (the normal is stored in a spheremap transformed format, so normal-z can and will be reconstructed correctly from this transformatiion again, and the specular power is stored as a 16-bit (8.8bit) fixed point value)
RT1 (R32F): linear depth (for viewspace&worldspace position reconstruction later in other shaders)

Light prepass rendering is a really good and mostly easy to implement extension for a already modular and object oriented forward rendering render implementation, for to have the most benefits of the good known deferred shading idea as well, without the whole transparency problems of a plain deferred shading render.

And the shown maps in this video are reflux and rebound from QuakeLive.


http://www.youtube.com/watch?v=h9ec0WfyvmM

[laggyluk]

nice :D
i think my lame gbuffer implementation uses 3 or 4 textures :(
btw packing stuff into less textures boosts fps or only saves up memory?

[BeRo]

btw packing stuff into less textures boosts fps or only saves up memory?

Both, but the performance improvements depends on the graphic card and is different from graphic card to graphic card.

More important is the pixel format of these GBuffer render-to-texture FBO textures for older graphic cards without good&fast support for floating point textures.