Index | FAQ | Search | Memberlist | Usergroups | Profile | Log in to check your private messages | Log in | Register

Discuss: Can we add Portals to Quake?

| Inside3d Forums Forum Index -> Engine Programming

View previous topic :: View next topic
Author | Message
--- | ---
heeen Joined: 26 Mar 2010 Posts: 2 |

Posted: Fri Mar 26, 2010 12:35 pm Post subject: Discuss: Can we add Portals to Quake? |

In case you don't know which portals I'm talking about: http://www.youtube.com/watch?v=fUlH5e1oH9w Portals as made popular in Portal (valve) and prey. But there's already mods with a portal gun! No one uses it! I'm not talking about a portal gun. I'm talking about adding a portal feature for mappers in new maps, or recompiling existing maps with some portals added.
People like their maps with old fashioend teleporters
Yes, we should not just replace all teleporters with portals. All the fun of telefragging and escaping throu teleporters would be gone.
Go ahead and implement it in QuakeC, then!
While this would maybe work, for proper portals, clients need to be able to render them. Also I don't know if you could handle collision detection correctly in QuakeC.
I propose adding Portals transparently underneath QuakeC. If you trace a line through a portal, the engine will automatically continue the trace on the other side of the portal and return collisions correctly. Some clever solution would be needed for lightning bolt effects: Due to a portal there are several ways to connect the start end end point of a lightning bolt.
Idea: cache the last traceline, if it crossed portal(s), use the crossing point(s) for the subsequent lightning effect.
By adding portals as an engine instead of mod feature, Noone has to touch existing mods like ktx or whatever people play.
Clients need a fall-back solution
I propose to not really care about this but leave it in the hands of the mapper. Mappers could then copy parts of the map behind the portal, simulating an actual portal for impaired clients. Or they could just add a white room, or a modified fluid surface to represent portals.
People will request the author of their favourite client to add portals proper.
How will collision through portals work
I guess you create a shadow copy of every entity that intersects a portal, where the shadow copy is the part of the entity that appears on the other side of the portal. Collision has to be accounted for on both sides.
How will rendering portals work

Render the portal "surface" in the stencil buffer.
Enable stencil test.
Render visible part of map on the other side transformed by the portal surface
recurse, if needed

Maybe add a particle effect if you're feeling fancy.
I wrote my last line of QuakeC 10+ years ago so maybe someone can enlighten me if most of this might already be possible.

Back to top |

heeen Joined: 26 Mar 2010 Posts: 2 |

Posted: Fri Mar 26, 2010 12:38 pm Post subject: |

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.

Back to top |

LordHavoc Joined: 05 Nov 2004 Posts: 243 Location: western Oregon, USA |

Posted: Fri Mar 26, 2010 1:18 pm Post subject: |

Rudolf Polzer implemented this in Nexuiz and has been trying to make it easy to drop the qc support code into other mods... http://www.youtube.com/watch?v=VfkMYYc8OSE But no consideration was given to fallbacks...

Back to top |

LordHavoc Joined: 05 Nov 2004 Posts: 243 Location: western Oregon, USA |

Posted: Fri Mar 26, 2010 1:49 pm Post subject: Re: Discuss: Can we add Portals to Quake? |

heeen wrote:
In case you don't know which portals I'm talking about: http://www.youtube.com/watch?v=fUlH5e1oH9w Portals as made popular in Portal (valve) and prey. But there's already mods with a portal gun! No one uses it! I'm not talking about a portal gun. I'm talking about adding a portal feature for mappers in new maps, or recompiling existing maps with some portals added.

Implementation differs somewhat for mapper-placed portals (where there can be an empty space behind the portal to allow players to move freely and the qc simply teleports them appropriately), vs collision-violating portals like in the game Portal (where essentially the engine has to make the collision system pretend there is empty space behind the portal, to allow a player to move in/out of it, without actually modifying the map geometry).

heeen wrote:
While this would maybe work, for proper portals, clients need to be able to render them. Also I don't know if you could handle collision detection correctly in QuakeC.

Collision yes, rendering can be faked in QuakeC also but only to a certain degree, it's very tedious.
In Duke3D the mirrors were done by putting dummy entities (visual only) on the opposite side of the mirror surface, there was an identical room on the far side, simply mirrored.
So that kind of proves you can do it with just QuakeC, but there are issues and serious limitations of map layout to consider of course.
On the rendering side, it can be hard for software to render portals... though I can certainly imagine how it could be implemented in a theoretical sense.

heeen wrote:
I propose adding Portals transparently underneath QuakeC. If you trace a line through a portal, the engine will automatically continue the trace on the other side of the portal and return collisions correctly. Some clever solution would be needed for lightning bolt effects: Due to a portal there are several ways to connect the start end end point of a lightning bolt.
Idea: cache the last traceline, if it crossed portal(s), use the crossing point(s) for the subsequent lightning effect.
By adding portals as an engine instead of mod feature, Noone has to touch existing mods like ktx or whatever people play.

For a variety of reasons, portals require QC code, including:

- Radius damage has to be "echoed" through the portals in its area of effect, to hit players on the other side, and give them correct momentum from the blast (more or less this means extra radius damage calls for each portal in the area of effect).
- Traces are not "straight" through a portal, if a lightning beam is drawn it will connect between the start and the end, which are in unrelated locations, one can not deduce the intent from these positions, which do NOT match the result of the traceline, because for example the qc puts the lightning beam end at several units beyond the end of the actual trace, it also does 3 tracelines in different positions, not one, so which one would describe the shot? difficult guesswork...
- Any object passing through a portal needs the EF_TELEPORT_BIT (DP-specific) flag set so that it does not incorrectly interpolate or draw a projectile trail between the old and new position, worse, this causes a gap in the trail, but that is less hideous than it drawing a huge particle trail across the map...
- AI (monsters, bots) are thoroughly confused when their line of sight trace hits a portal and ends up in some odd position, their code may be doing things involving trace_fraction and the end vector they passed in, not even using the trace_endpos...
- Bullet damage through a portal pushes the player in the wrong direction, because the damage call passed the shooter as the inflictor, so the direction from inflictor to target is NOT a straight line, but the QC thinks it is, so it pushes you in the wrong direction, this happens anytime the inflictor is not on the same side of the portal as the target.

heeen wrote:
Clients need a fall-back solution I propose to not really care about this but leave it in the hands of the mapper. Mappers could then copy parts of the map behind the portal, simulating an actual portal for impaired clients. Or they could just add a white room, or a modified fluid surface to represent portals.
People will request the author of their favourite client to add portals proper.

As this requires additional network protocol (describing the portals), or some clever parsing of entities in the client (which most engines do not do), you may have a difficult challenge here...
Really the clientside entity parsing (DP and certain others) or selective networking (FTEQW) are the only ways that do not lead to direct incompatibility.

heeen wrote:
How will collision through portals work I guess you create a shadow copy of every entity that intersects a portal, where the shadow copy is the part of the entity that appears on the other side of the portal. Collision has to be accounted for on both sides.

This is exactly right, and normally that shadow copy is done by QC.

heeen wrote:
How will rendering portals work

Render the portal "surface" in the stencil buffer.
Enable stencil test.
Render visible part of map on the other side transformed by the portal surface
recurse, if needed

Actually the stencil buffer is used by shadows in a number of engines, so that isn't an option...
There is an interesting depth-partitioning technique that can be used - divide the depth buffer into ranges based on how many levels of portal recursion are on the screen, render the scenes back to front with depth-only polygons over the portal that they are seen through, so that each new partition protects the pixels of the views beyond it, at least where they are not behind walls of this view.
DarkPlaces however uses render to texture for this purpose, which enables fancier portals like irregular outlines and other shader-based effects.
But DarkPlaces only renders these on hardware that supports shaders...

heeen wrote:
Maybe add a particle effect if you're feeling fancy.

Often the undecorated portal is the most interesting, or at least most surprising.

heeen wrote:
I wrote my last line of QuakeC 10+ years ago so maybe someone can enlighten me if most of this might already be possible.

Write more!
Regarding your notes about view directions, teleporters in Quake never had to be graceful, they changed the player angles abruptly to a specific value, where as this has been fluid, the angles need an adjustment, a delta to be applied to them, which requires a new svc_ network event for the delta angles.
Worth noting that you often have to consider their old angles, do the math in matrix form (forward, right, up) and then convert back to angles using vectoangles, and yes, the up vector is not preserved in this because vectoangles only takes a forward vector, but that's okay because you don't want view roll in most cases anyway (the engine doesn't let the user modify it, and it doesn't do what you want in most cases).

Back to top |

Teiman Joined: 03 Jun 2007 Posts: 309 |

Posted: Fri Mar 26, 2010 2:48 pm Post subject: |

LordHavoc wrote:
Rudolf Polzer implemented this in Nexuiz and has been trying to make it easy to drop the qc support code into other mods... http://www.youtube.com/watch?v=VfkMYYc8OSE But no consideration was given to fallbacks...

Wow.. I love how this video look. The portal thing is beyond, me, but I love the contrast of the map, the nice looking of the lava. It looks brilliant!.

Back to top |

div0 Joined: 26 Mar 2010 Posts: 4 |

Posted: Sat Mar 27, 2010 6:37 am Post subject: |

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

Back to top |

Teiman Joined: 03 Jun 2007 Posts: 309 |

Posted: Sat Mar 27, 2010 10:04 am Post subject: |

:-O

Back to top |

metlslime Joined: 05 Feb 2008 Posts: 177 |

Posted: Sat Mar 27, 2010 9:22 pm Post subject: |

wow, nice work... on the "cube" video, did you have to make the skybox symmetrical and identical on all 6 faces so you wouldn't see any popping?

Back to top |

div0 Joined: 26 Mar 2010 Posts: 4 |

Posted: Sat Mar 27, 2010 9:38 pm Post subject: |

Yes, I had to, because otherwise the skybox would look different through the warp than directly.

Back to top |

Urre Joined: 05 Nov 2004 Posts: 1073 Location: Sweden |

Posted: Sun Mar 28, 2010 9:24 am Post subject: |

div0: I'm assuming they're not dynamic simply by design rather than limitation? In other words, one could use the engine-features involved to write dynamic warpzones in QC? I can see it involving funky stuff with making entities nonsolid in vicinity of warpzones to move through geometry and stuff, perhaps tracelines on the corners of the boundingbox... Really cool and mindtickling things to try and design
_________________
Look out for Twigboy

Back to top |

div0 Joined: 26 Mar 2010 Posts: 4 |

Posted: Sun Mar 28, 2010 1:15 pm Post subject: |

The QC code only supports static ones - however, you can e.g. add your own code to update SendFlags when the warpzone got moved, to allow them to be movable. However, in any case, they NEED empty space behind them. THAT requirement cannot be removed.
You maybe can "approximate" Portal's portals by making a wall out of many func_door like entities, and making a portal creation first move some of the doors back... but I doubt this can get good and bugfree gameplay.

Back to top |

Urre Joined: 05 Nov 2004 Posts: 1073 Location: Sweden |

Posted: Sun Mar 28, 2010 6:48 pm Post subject: |

What exactly is it that needs empty space behind them? If it's the physics, I'd say they don't need it. _________________ Look out for Twigboy

Back to top |

div0 Joined: 26 Mar 2010 Posts: 4 |

Posted: Mon Mar 29, 2010 5:27 am Post subject: |

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.

Back to top |

Teiman Joined: 03 Jun 2007 Posts: 309 |

Posted: Mon Mar 29, 2010 1:10 pm Post subject: |

div0 wrote:
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.

Maybe add a .phisic_offset attribute, where the phisic position (the one where all collisions and things are tested) is different from the real position (where the player will be render).
I don't know if that would make the problem easier, or much harder (-:

Back to top |

Urre Joined: 05 Nov 2004 Posts: 1073 Location: Sweden |

Posted: Tue Mar 30, 2010 10:32 pm Post subject: |

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?
_________________
Look out for Twigboy

Back to top |

Display posts from previous:

| Inside3d Forums Forum Index -> Engine Programming | All times are GMT
Page 1 of 1

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2004 phpBB Group