FTE QW engine.

[Spike]

yes, it can run standalone q3 mods, however its not very well tested for q3, and mods will take the brunt of that. if you want q3 specifically, its currently still better to stick with q3-only engines.

client gamecode is linked to protocol. protocol is linked to server gamecode. using csqc with q2 or q3 protocols/serverside-gamecode will not work, even if you hacked the engine to try loading it, the game data would not be directly accessible and would require a whole new set of builtins. q2 less so, but q3's gamecode and protocol are strongly linked thanks to the gamecode providing all sorts of prediction and other stuff - if the cgame and [s]game don't match then all bets are off.

there is a single exception in that fte servers can potentially allow q3 clients to connect to q1 gamecode. this is basically totally untested, and would require some very specific custom q3 gamecode for it to actually work. providing compatible models would be an even bigger nightmare. so its probably best to consider this a misfeature and ignore that I even mentioned it. mixing and matching isn't always for the best.

menu.dat or q3ui are much less strongly linked, but also much less interesting to mix.

[Julius]

Another question: is it possible to add some sort of ocean effect with the terrain? I.e. a water surface that extends all the way to the horizon. I believe that isn't possible to just map (without killing performance), but needs some sort of engine support, like the case for example in Cube2: Sauerbraten: https://youtu.be/GUdrDAkRJeE

Even better with a system that detects intersection with the terrain and adds some different water colors and some foam (and caustics under water?) to the water shader like 0AD can do? See: https://wildfiregames.com/forum/inde...comment=271861

[Spike]

you can add some worldspawn fields to configure the default section

_defaultgroundtexture "city4_2"
_defaultwatertexture "*water2"
_defaultgroundheight -1024
_defaultwaterheight 0 //hurrah, sea level.
then the default tile is underwater, giving you a nice big ocean type thing.

if you want waves and foam and other extra stuff, then you'll need to modify the glsl, which gets quite complicated (foam needs depth info, I *think* you can get that with refraction fbos, but its a bit more expensive).

[Mugwump]

I.e. a water surface that extends all the way to the horizon.

That would be great in maps like Avanipaala Praasaada where the "ocean" abruptly stops at the end of the bay.

[Julius]

We shortly discussed in that other thread that a mobile VR port of FTEQW might be legally possible if it is true that Google Daydream is an integral part of Android N, but actually it might be even more interesting to implement it in the WebGL port via WebVR? That way all major VR systems would be supported without extra effort.

Some links:
Responsive WebVR, headset optional | Boris Smus
https://github.com/borismus/webvr-boilerplate

edit: this also has an emulator to test it without a headset: https://webvr.info/
(So you need to find a new excuse :p )

[Mugwump]

How do you emulate VR without stereo vision?

[Spike]

r_stereo_method 5
then go cross-eyed...
yay 3d!
also, enjoy the eye strain.

that's basically what that 'emulator' does, just realtime instead of a fancy screenshot.
and with some external way to change the head angles, which has some obvious user interface issues but is better than nothing.

side note:
screenshot_vr foo.png 2048
open the resulting screenshot in a vr program that understands the distortion.
note that taking such a screenshot requires capturing a whole load of slices, which involves a LOT more rendering right now than it really should.
fte also has screenshot_stereo which takes a stereographic screenshot, and screenshot_mega which does not override the projection. All 3 use offscreen rendering rather than capturing what's actually on the screen, so they are not limited by your window/screen size, and likely miss a few things like the console or menus.

adding support for webvr would apparently require setting up a framebuffer/canvas using the webvr framework (fuck frameworks! should be possible to wrap a whole load of code, but needing to enable it from eg a mouse click is annoying), with fte's r_stereo_method cvar set to 5 and some extra code to use the api's view+projection matricies (which has scaling issues due to quake using quake-units instead of metres).
tbh the biggest issue is dealing with the viewer's origin. which I'm almost sure would end up wrong...
probably need to make sure the webgl port supports controllers properly first or something.
its certainly doable, it still needs a time investment though

[Julius]

For WebVR: looks like there is relatively solid support in Chrome now:
https://blog.chromium.org/2016/12/in...hrome-for.html

Also note the gamepad extensions:
https://w3c.github.io/gamepad/extensions.html
(it seems they support the Daydream controller, which would be really neat).

Edit: saw in the changelog of the 2016-12-19 version that preliminary WebVR support is done? Awesome! How can I test it best (I only have a Android Cardboard headset).

[Spike]

I've only tested it with some chrome fake-vr extension, so it probably doesn't even work anywhere else.
I tried to get it to autodetect when a headset was on+enabled, in which case it'll just work. It'll also listen to events related to the user putting their headset on and activate then too. If your browser doesn't report that the headset is worn nor already enabled then you're probably screwed right now.

don't expect the menus/hud/console to be even slightly usable with vr. It'd be really cool to make some 'settings map' to replace the menus, with big clunky buttons to enable/disable stuff, and entire corridors to switch presets or load/save games etc, because that's kinda quake's style. Unfortunately I'm not much of a mapper, and too lazy to write the required csqc (but my purecsqc mod implies that it should be possible to save games with it, or make a server browser...).

[Mugwump]

It'd be really cool to make some 'settings map' to replace the menus, with big clunky buttons to enable/disable stuff, and entire corridors to switch presets or load/save games etc, because that's kinda quake's style.

I love the idea.

[Julius]

The normal quake menu works quite ok in the Darkplaces VR port. I think it is just being rendered onto a polygon in 3d space. See: https://github.com/poVoq/Quake-1-Cardboard-Port-QVR
Of course you need a controller to use it.

Cardboard does not have any way to signal the system that is is being enabled (I think Daydream has now though, if you have the official headset). So a way to enable or toggle it in the menu would be good to have.

[Julius]

More thoughts on VR... (yeah I should stop bothering you, but I think the Quake engine has a potential sweet-spot as a mobile VR & AR engine and FTEQW is the only Quake engine that is actively developed with advanced features in mind.):

So why not turn the relative weakness that there is no deferred rendering option into a strength for VR:

https://ustwo.com/blog/vr-distortion...x-displacement

[nahuel]

[ame="http://www.youtube.com/watch?v=NJoZUcP_Nyg"]http://www.youtube.com/watch?v=NJoZUcP_Nyg[/ame]

toneddu2000 is coding a real time editor for fte maps

check the thread InsideQC Forums • View topic - [FTEQW][WIP] Crafter - realtime game editor for FTE

[Mugwump]

@Crafter looks neat!

[trigram777]

Long time lurker, first time poster. FTEQW has become my go-to Quake client, but there's a minor issue I'm having with decals/stains. All of this is using the "Haze" particle set, the QRP texture set w/ normals, and using the latest client (SVN 5077). It seems that stains (blood on the walls, bullet holes, rocket craters) don't work at all on my setup if realtime world lighting is enabled. They work fine with every other setting, but turning on realtime lighting causes all stains and decals to vanish. It also appears to cause some particle emissions to have wrong RGB values (blood particles look almost pink). Is there a setting to tweak this, or are stains not compatible with RT lighting?

When stains do work, there seems to be a very low limit to how many can exist at the same time. I tried increasing both maxdecals and maxparticles in the console, but neither seem to affect the amount of blood/weapon stains supported. It's low enough that one gibbed monster produces too many blood stains and the engine starts removing them. In Darkplaces when you bump up the decal limit in the console, it does work as expected -- you can paint the whole level red and it'll keep up.

I know this is totally silly and trivial, but if there's a way to make stains work with realtime lighting and support more of them at once, it'd be much appreciated.