Discuss: Can we add Portals to Quake?

[heeen]

[heeen]

Some more issues to think about:
players passing through a portal may have their view at an angle that is not a valid viewing direction. this should be handled gracefully.

Also client side movement prediction has to be considered.

Clients will have to receive events from the other side of the portals to even see and hear whats going on on the other sied of the map.
Sounds need to be transformed into the local space.

[LordHavoc]

Rudolf Polzer implemented this in Nexuiz and has been trying to make it easy to drop the qc support code into other mods...



But no consideration was given to fallbacks...

[LordHavoc]

[Teiman]

[div0]

I have a working implementation of warpzones in Nexuiz and DarkPlaces, using
however mostly QC and CSQC code and only rendering parts (and server-side
culling parts) in the engine.

I called them warpzones, consistent with unreal engine's warpzones, as they are
NOT dynamic portals like in Portal (basically, because they need nonsolid space
behind them).

Later, I will:
- port this code to id1 QC, using a dummy CSQC codebase that lets the engine
handle e.g. scoreboard, prediction, etc.; also license the code under the MIT
license which is compatible to about any use, including GPL and commercial
use
- move certain parts to the engine for acceleration

Stuff that probably can be moved to the engine:
- functions to deal with "angle transforms", i.e. rotation matrices encoded in
pitch-yaw-roll angles. Would give the advantage that they no longer would
clobber v_forward, v_right, v_up.
- the warpzone-aware traceline, tracebox, findradius
- the auto-teleport-entity-if-on-warpzone code (i.e. "warpzone-aware movetypes")

Stuff QC still has to do:
- network the warpzone entities to the client
- parse and spawn the warpzone entities on the server (but MAYBE one could make
a special hack when parsing the map for this)
- the trace functions have to provide extra info to give QC info about the
orientation of the warpzones passed; QC code still needs to be adapted to use
that info, or e.g. hit directions, damage through warpzones, will not behave
right
- in special occasions, QC must have the choice to perform a warpzone-ignoring
trace

Current limitations:
- no entity duplicating is done yet, so if a player stands "on a warpzone
plane", only half of him can be seen. However, at least in Nexuiz, this
doesn't seem too serious, as one always sees the "bigger half". Will get
fixed when I port it to id1.
- fixed lights need to be duplicated behind warpzones to prevent lightmap
seams; when using radiosity, this can become quite a chore.
- realtime lights cannot be fully duplicated. One could perform the duplication
trick as usual, but then has to make sure the space behind a warpzone is
large enough to fit a whole realtime light radius
- My engine code for it is based on DP's refraction code, and can only perform
one iteration of warpzones. Thus, one has to avoid warpzones that can see
other warpzones.

Improvements over Unreal's warpzones:
- hitscan is warpzone aware
- radius damage is "mostly warpzone aware" (it cheats a bit and does not yield
perfect circular damage, but a line of sight and the distance between
explosion and target can be correctly checked; if you insist on perfect
correctness, probably calling the warpzone aware findradius with a higher
radius, and then manually checking line of sight and distance, will work fine
then)
- even the fastest projectiles are warpzone aware (implemented by a function
that must be called in all touch functions at the beginning to check if the
projectile is inside a warpzone, and if yes, teleport it to the other side,
push it back to the warp plane, and abort the collision)
- it is impossible to get inside the "warpzone space"

Videos of it, apart from the one farther above:

http://www.youtube.com/watch?v=qPMFOp3YtDI
http://www.youtube.com/watch?v=5-8atWDlfhY

[Teiman]

[metlslime]

[div0]

[Urre]

[div0]

[Urre]

[div0]

It of course is the physics.

If anyone manages to find a way to get rid of that restriction, go ahead. But I don't think that is possible in DarkPlaces.

[Teiman]

[Urre]

A spontaneous idea that comes to mind is creating a hull around the warpzone which has its own physics applied on the double player entities involved (one on both sides), and restrict movement of both entities to the boundaries inside the outer edges of this hull, ignoring geometry. You'd probably need to code your own MOVETYPE_WALK in QC (not hard, I use it by default nowadays) which checks in advance wether or not the warpzone plane will be crossed, and apply the warpzone specific physics instead.

How would Valve do it if not insane hackery?