Re: [CsMain] Linking portals at runtime

Dominik Seifert <[email protected]> Sat, 18 Aug 2012 19:20:40 +0100 (BST)
Newsgroups gmane.comp.graphics.crystalspace.general
Message-ID <[email protected]>
On 18 August 2012 17:05, Andrei B?rsan <[email protected]> wrote:

> > On 18.08.2012 18:59, Mat Sutcliffe wrote:
> > > So it is possible to connect a portal to a position where there is no
> > > corresponding portal, to create a "one-way" portal, or to have a
> > > corresponding portal point somewhere else entirely, for all sorts of
> > > confusing game mechanics. :)
> >
> > Hehe, reminds me of the portals in Quake III, actually!
> > It would really be nice to see in CS.
> >

> Also in Quake 1. The intro level where you chose the difficulty by jumping
> through either the easy, medium or hard portal (there was a secret
> nightmare portal too IIRC). They all led to the same place, but each one
> set the difficulty variable to a different value. Pretty neat. 


I think portals need their own GSoC participant tbh. Currently there are all kinds of issues with them, and they also need a few additional features.

The issues that I currently recall (and of which some are already on the bug tracker) are:

1. Z-Fighting issue with underlying (wall-) texture - Would be best if that can be handled more smoothly than just moving the portal out a bit. The "moving out fix" does not fix it for all situations because the depth buffer has a too small resolution (From what I understand, many AAA games have a 128 bit z-buffer or other techniques to avoid z-fighting by improving z-buffer resolution).

2. Clipping issue when getting too close - It is exactly what it says: When you get too close, the portal plane is clipped away and you see the wall or w/e other object is behind it. Apparently only some have this.

3. For some reason, no one could give me a 100% working formula for warping from one world transform to another (for example for same-sector portals, like those in Quake). I tried a lot of things, but none worked 100% correctly. I know that it has been done before, but I don't know what magic was involved in making it work. One of the issues that I encountered was that the portal warp visually moved - When I looked at it from some angle, it looked correct, when I looked at it from further away, I suddenly saw the wall right behind the portal. So the world-position of the warp somehow seemed to move from "inside the portal" to "behind the portal". That happened in a large empty box-kind of level (side-length of about 50 units).

3b. Warping should ideally be done in world coordinates, so they also keep working when portals are moved etc. I did not try the STATIC flag - That might fix it. Funnily the portal raytrace method always seems to assume warps to be in the world reference frame, whereas rendering does not.

4. The engine's CreatePortal method creates a portal mesh, and it has an optional position, even though the mesh already has a movable with a transform. Either it should require a transform, or nothing at all?


5. The portal core seems to determine the portal's normal, solely from it's polygon, and disregards the mesh's rotation.

6. Portal mesh normals are reversed. The normal of the polygon is pointing in the same direction as the camera. If they are opposite (i.e. if we look at the frontface of the mesh), the mesh is (frontface-)culled. (This might be customizable, a bug or a feature :)

7. There is some crash bug that occasionally happens somewhere deep in the SetupHeavyPortal method - At least in levels that render 2 portals that warp toward each other within the same sector.


In order to have portals do stuff upon traversal (like setting the difficulty settings, as mentioned above), a new feature needs to be added: A portal traversal event. In fact, physics also needs that to make sure that purely vertical actors are re-aligned with the up-axis after traversing, which is why that kind of event will be added to the physics2 plugin anyway (it would not make sense to have that sort of game logic in the rendering API of portals anyway).

Portals need an indicator as to whether they may be traversed at all. I can imagine that portals can also be used for screens that show live camera feed from some other part of the game (like you see it a lot in Deus Ex and many other games). Obviously, the physics engine needs to know that it should not port objects that come sufficiently close to the ingame screen that is represented by that portal.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

_______________________________________________
Crystal-main mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/crystal-main
Unsubscribe: mailto:[email protected]?subject=unsubscribe