outdoor engines (was Re: Deus Ex Team doing Thief 3)
Eep²
> On Fri, 11 Aug 2000 21:50:35 -0700, Eep² <e...@tnlc.com> wrote:
>
> >FAKK2 is still a portal engine. Its open areas are about as expansive as Tomb Raider's,
> >which is also a portal engine. Active Worlds, Drakan, Trespasser, Outcast, 10six, and
> >Deus Ex (Unreal) have truer outdoor engines.
> >
> >Harvester wrote:
> >
> >> On 11 Aug 2000 09:06:35 GMT, who...@wherever.com wrote:
> >>
> >> >: We'll have to see that, once a Q3A engine game with open areas arrives...
> >> >
> >> >Exactly.
> >>
> >> what about FAKK2? I haven't played the game personally, but it seems
> >> like it has some open area levels...I wish they would hurry up and put
> >> a demo ut
>
> Even the Unreal engine is indoor (portal-based) at heart -- it just
> does it really well.
Well then Unreal has REALLY big portals then. But just because a game's levels has high cliffs/walls doesn't make it a portal engine. While the other game engines I mentioned tend to have more expansive levels/worlds, they could also have high cliffs/walls to simulate a portal engine.
Rainer Deyke
> Well then Unreal has REALLY big portals then. But just because a game's
levels has high cliffs/walls doesn't make it a portal engine. While the
other game engines I mentioned tend to have more expansive levels/worlds,
they could also have high cliffs/walls to simulate a portal engine.
>
Whether or not an engine has high cliffs/walls has nothing to with whether
or not it is a portal engine. The term "portal engine" refers to the
internal technology - you can't see whether an engine is a portal engine or
not just by looking at its output.
--
Rainer Deyke (ro...@rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor
Eep²
> "Eep²" <e...@tnlc.com> wrote in message news:3995F37C...@tnlc.com...
> > Well then Unreal has REALLY big portals then. But just because a game's
> levels has high cliffs/walls doesn't make it a portal engine. While the
> other game engines I mentioned tend to have more expansive levels/worlds,
> they could also have high cliffs/walls to simulate a portal engine.
> >
>
> Whether or not an engine has high cliffs/walls has nothing to with whether
> or not it is a portal engine. The term "portal engine" refers to the
> internal technology - you can't see whether an engine is a portal engine or
> not just by looking at its output.
Not implicitly, but it's common (if not standard) in portal engine levels to use high cliffs and walls.
sswift
>Whether or not an engine has high cliffs/walls has nothing to with whether
>or not it is a portal engine. The term "portal engine" refers to the
>internal technology - you can't see whether an engine is a portal engine or
>not just by looking at its output.
Well that's not entirely true...
A portal engine is an engine where if you say, have a door, or any
opening really, it acts as a magical "window" into the next area.
Polygons which can be seen through this window are clipped to it's
edges before being drawn, and only those that can be seen are drawn.
In games which do not use portals, a door is just an ordinary hole,
and polygons drawn behind it are drawn first in their entirety, even
the ones that can't be seen through the hole, and then the hole is
drawn on TOP of them.
The clipping done to render an opening as a portal is slow... so a
small room drawn with portals would go slow. But on the other hand,
because portal engines only draw what it seen, for many kinds of
scenes they will render stuff faster.
Here's a few examples:
Example 1:
A portal engine could render an area with a building with a ton of
stuff inside it and maintain a decent framerate because once it hits
the door to the building, it wouldn't render everything inside it.
A regular engine on the other hand would probably try to render
everything inside the building.
Example 2:
Imagine you have a city with lots of tall buildings... buildings which
block the player's view of other buildings behind them would reduce
the polygon count in a portal engine, because stuff ebhind them
wouldn't be drawn.
But in a regular engine, it wouldn't know that building blocks
visibility and it would render all the buildings behind it.
Example 3:
You're outdoors in a huge hilly area, with a giant castle off in the
distance in one direction, and a forest in another. A huge hill
seperates the two.
A regular engine would render everything and it would trender really
slow.
A portal engine would clip everything when it gets to the hill which
hides the castle on the other side of it. So it would render the
world faster.
Of course, when I say "regular engine" I'm just generalizing
non-portal engines. Non-portal engines have methods of optimization
too... like the Quake engine have PVS technology, which I won't go
into an explantation of unless someone asks. That technology would
porbably allow example 1 and 3 to run at a decent rate, but it might
not handle example 2 very well.
Regular engines have advantages too though. Many kinds of scenes
render fastest without portal technology. Indoor scenes like those in
Quake 3 for example. A purely portal based engine might have a really
hard time handing smoothly curving architecte.
Of course, few engines are purely portal based or purely PVS or
whatever based. The Quake engines for example support portals, but
the level designer needs to place them where they want them... So they
can make sure they go in the areas that will help most and they won't
show up everywhere and slow everything else down.
Oh, and another advantage of purely portal based engines is that since
the portals are calculated in realtime, it makes having moving
geometry really easy.
But I still haven't gotten to the point of my response... you know,
where I said that that wasn't entirely true?
You CAN tell if an engine uses portal technology simply by looking at
it... but only if the designers were creative with how they used it.
If you see a mirror on a wall, and you can walk around behind it, then
you're in a portal based engine... probably. And if you see a
floating "portal" which you can see other parts of the world through,
but you can walk around behind, that's a portal too.
Of course, oddly, Duke Nukem 3D uses portals, but there are
limitations on things like mirrors which make it hard to make areas
where you can walk around behind them... But it is possible to do
it... you just have to make sure you can't see that area at the same
time as you are looking through the mirror... of course, I've seen
even that rule broken with sliding mirrors which act like doors, using
clever level design. :)
Usually when you see floating portals in mid air though, it's a portal
engine.
Moritz Raguschat
what a portal engine is? Some of you talk about a portal engine as an engine
that renders big outside worlds. I think that is a very vague definition (if
it is a definition at all). And now one of you says that some internal
technology makes a portal engine. But what technology is it? What is the
technical difference between a portal engine and a "normal" engine?
Carl Scheffler
FlipCode.
http://www.flipcode.com/portal/
Carl
Quatoria
ssw...@NOearthlinkSPAM.net (sswift) wrote:
> But it is possible to do
>it... you just have to make sure you can't see that area at the same
>time as you are looking through the mirror... of course, I've seen
>even that rule broken with sliding mirrors which act like doors, using
>clever level design. :)
Like in Deus Ex, which you hated for its crappy level design.
-Quatoria
--
In this unpredictable, oftentimes contentious world,
sometimes you just have to sit back, take a moment to
reflect, and say "Well, I'll be a greased Jesus!"
erik robson
<blu...@diespamdie.ii.net> wrote:
>> A portal engine could render an area with a building with a ton of
>> stuff inside it and maintain a decent framerate because once it hits
>> the door to the building, it wouldn't render everything inside it.
>
>I don't think this is correct. Isn't the whole point of a BSP tree that the
>engine will not try to render objects obscured by other polygons?
>
>
>
It really depends on the engine, how it uses BSP trees, how it uses
portals, etc. In the Quake 3 engine, you'd have the landscape with
the building, but the building would need a door that literally
toggled rendering of the interior (assuming you're on the outside.)
If you left the door (and areaportal) out, the engine would render
everything inside the building.
In the Unreal engine, you'd simply place a "portal sheet" at the door
and the engine would manage the rest of it, only rendering visible
polys through a combination of portals and a span-buffer.
James M
is one, followed by a few corrections to previous posts.
Portal based systems come in two varieties: pre-calculated and
real-time, but they both work on the same principal. The idea is
that you have "cells" which are fairly self contained areas,
such as rooms. Then, you have "portals" that connect
the "cells." The portals represent the ONLY way to see from cell
to cell.
When you draw the level, you first draw the cell the viewpoint
is in. Then, you see if any of the portals in the cell are
visible. If they are not (for example, you are facing a wall)
the drawing is done. If a portal is visible, you must render the
next cell that the portal is attached to. This can be done with
some combination of stencil buffers, z buffers and hand-clipping
against the portal area.
Here is an example: we are in a room, looking through a door
into another room, which has another door into a third room. We
draw the first room, then a quick check tells us that the portal
to the second room is visible. So, we stencil out the area of
the portal, so that only the open doorway will get overdrawn.
(This is more important when the portal is a "magic" portal that
can go to any space that is not really attached in the normal
sense) Then we take our viewing frustrum and perform some math
with the portal (or perhaps a rectangle approximation) to create
a new, slimmer viewing frustrum. We can clip objects in the next
room against this frustrum to see if they are visible or not, OR
*at the least* we use this new frustrum to see if the next
portal is visible. If it isn't, we don't have to draw the third
room. We *MUST* make this sort of check, or else we will
stupidly draw *every* cell and end up not getting any saving.
Pre-calculated cells are faster, but doing them in real time
allows you to move geometry around seamlessly. For example, you
can magically switch the kitchen and bathroom of a house, have a
maze of sliding rooms, etc. Portals are also useful for
reflections and "warps" where the portal is a sort of
transporter or viewing screen that lets you see and/or move to
some distant location.
Portals are also useful is dividing up the space of a level for
purposes of collision and loading. You only have to perform
collision for objects in the same cells, and if the level is too
large to be loaded all at once you can load and unload cells
based on how many portals they are away from the current cell.
The best thing about portals is that, say you can assure that
only 3 cells are visible at once. Then you can design any 3
cells so that together they max out you poly count, and you are
still safe. The idea in general is that rooms can be *very*
detailed because you never even have to consider the details of
most other rooms. You don't have to actively cull them out; you
just never deal with them at all unless you have specific reason
to.
Now, you *could* get sort of the same thing by simply designing
the levels properly, and either running an algorithm or just by
hand figuring out what you can see from anyplace else. For
example, I might be able to tell that if I am in one room in a
Quake level the farthest I can see is two rooms in any
direction. The problem with this is that the geometry can not
really be dynamic at all. Doing a lot of sliding walls,
elevators, moving rooms, etc becomes quite a pain, because an
elevator that slides around may have certain areas visible or
not visible depending on how high it is. There are work-arounds,
and in real life few buildings have many moving parts, but in
games it can be restrictive.
So, that is portals. Now, some corrections:
ssw...@NOearthlinkSPAM.net (sswift) wrote:
>"Rainer Deyke" <ro...@rainerdeyke.com> wrote:
>The clipping done to render an opening as a portal is slow...
so a
>small room drawn with portals would go slow.
Well, sort of. If you are using a stencil buffer you don't have
to actually clip anything against the portal at all, you just
have to see which portals are visible from the new viewing
frustrum. And for curved portals you can simply approximate the
portal as a rectange, as long as you do the stenciling
correctly. (I mean, actually stencil a circle say, but do the
math on a bounding rect) If you want to clip yourself you can
add clipping planes if supported, or simply clip objects rather
than actual polys and let the stencil buffer do the rest. Even
if you do NO clipping at all other than the stencil buffer it
can be alright depending on how the world is set up. (For
example, if you have a pinhole window in a wall looking out on
the entire outdoors, you probably want to do some sort of
clipping)
But on the other hand,
>because portal engines only draw what it seen, for many kinds of
>scenes they will render stuff faster.
>
>Here's a few examples:
[clip example 1]
>Example 2:
>Imagine you have a city with lots of tall buildings...
buildings which
>block the player's view of other buildings behind them would
reduce
>the polygon count in a portal engine, because stuff ebhind them
>wouldn't be drawn.
Yes, sort of, but this is getting into the realm of occlusion
more so than portals. A portal is an opening in an otherwised
closed space, whereas occlusion is a big object in an otherwise
open space. On something like very tall city blocks you can have
the portals be alleyways, but for a singular big building I
wouldn't really call it portal based.
>Example 3:
>You're outdoors in a huge hilly area, with a giant castle off
in the
>distance in one direction, and a forest in another. A huge hill
>seperates the two.
Once again, if there is more open than closed space, instead of
cells and portals (where are the cells outdoors?) it makes more
sense to use occlusion. Basically you mark the hill as an "anti-
portal" (as in, you can't see around it) and perform a similar
frustrum/viewpoint check. If the hill is in our frustrum, we can
create a new frustrum the represents where we can see around it.
Now, this is very similar to portals, but not really the same in
that we are marking occluders instead of holes, which makes
sense because in outdoors there aren't really holes in a
otherwise solid wall. Of course, they would share most of the
same math, although the 3d nature of the occluder would make
things a bit trickier.
[clip]
>Of course, few engines are purely portal based or purely PVS or
>whatever based. The Quake engines for example support portals,
but
>the level designer needs to place them where they want them...
So they
>can make sure they go in the areas that will help most and they
won't
>show up everywhere and slow everything else down.
Hmmm...I would have guessed that was how every portal based
system works. I guess in a "pure" portal based engine every cell
must be convex, but I doubt if anyone really does things this
way. For some levels it might make sense just to have each cell
be one half of the entire level, with one portal in some
corridor connecting them.
James M
-----------------------------------------------------------
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
sswift
>> A portal engine could render an area with a building with a ton of
>> stuff inside it and maintain a decent framerate because once it hits
>> the door to the building, it wouldn't render everything inside it.
>
>I don't think this is correct. Isn't the whole point of a BSP tree that the
>engine will not try to render objects obscured by other polygons?
As far as I know, a BSP only tells you what ORDER to draw the polygons
in.
I'm guessing Carmack didn't think long and hard for weeks trying to
figure out how to determine visibility in a 3D BSP tree for nothing...
Visibility determination in Quake is done with a PVS, which is
something which basically splits the world up into convex hulls
(spaces) and it stores how they interconnect. Then you figure out
which hull the player is in and draw the hulls in back to front order.
The PVS stores which hulls are visible from each specific hull...
basically the game knows which rooms can be seen, even a teesny little
bit, from the current room. This saves a lot of tme figuring out
exactly which polygons are visible, but of course if you have a big
detailed room you only see a little sliver of, it's gonna draw all
those polygons anyhow. Of course you could do more visibility tests
to help with this.
The BSP tree just tells Quake what order to draw the potentially
visible polygons in.
Eep²
> In article <3996A05A...@tnlc.com>, =?iso-8859-1?Q?Eep=B2?=
> <e...@tnlc.com> wrote:
>
> > Rainer Deyke wrote:
> >
> > > "Eep²" <e...@tnlc.com> wrote in message news:3995F37C...@tnlc.com...
> > > > Well then Unreal has REALLY big portals then. But just because a game's
> > > levels has high cliffs/walls doesn't make it a portal engine. While the
> > > other game engines I mentioned tend to have more expansive levels/worlds,
> > > they could also have high cliffs/walls to simulate a portal engine.
> > > >
> > >
> > > Whether or not an engine has high cliffs/walls has nothing to with whether
> > > or not it is a portal engine. The term "portal engine" refers to the
> > > internal technology - you can't see whether an engine is a portal engine or
> > > not just by looking at its output.
> >
> > Not implicitly, but it's common (if not standard) in portal engine
> levels to use high cliffs and walls.
>
> It's also common to see high cliffs and walls in outdoorsy levels built in
> BSP/PVS engines. It's just a fact of life in building stuff for realtime
> display... polycount matters, and high walls and cliffs are the best way
> to cut off views.
Got some game examples with non-portal engines that use BSPs and PVSes (?) with high cliffs/walls? I thought all portal engines used BSPs...
mr bernard langham
sswift
>In the swirling mists of history, on Sun, 13 Aug 2000 13:36:59 GMT,
>ssw...@NOearthlinkSPAM.net (sswift) wrote:
>
>> But it is possible to do
>>it... you just have to make sure you can't see that area at the same
>>time as you are looking through the mirror... of course, I've seen
>>even that rule broken with sliding mirrors which act like doors, using
>>clever level design. :)
>
>Like in Deus Ex, which you hated for its crappy level design.
Deus EX had sliding glass mirrors?
I don't understand the point of mentioning that I don't like Deus Ex's
level design, unless you're implying that the Deux Ex level designers
needed to be just as clever as the ones who made Duke levels to make
sliding glass mirrors. That's not the case, because Unreal doesn't
have the kind of problems Duke has with mirrors. Making a sliding
mirror door would be a peice of cake in Unreal... it's portal
rendering works correctly.
sswift
I already explained it, in another message, but I'll try to simplify.
Imageine a blue sheet of paper with a square hole in it. Put a red
sheet of paper behind it.
A portal engine would be like using a razorblade, and cutting around
the edge of the hole in the blue sheet so that all the parts of the
red paper which can't be seen through the hole can be removed.
A regular engine wouldn't do that cutting. And a regular engine would
have to draw all the unseen stuff, the whole of the red paper, first,
and then draw the blue paper on top of it. Where the hole isn't, you
have "overdraw". The 3D card has to draw those pixels twice.
A portal engine on the other hand cuts the "paper" (polygons) like I
described above. Because it does that, it doesn't even matter if you
draw back to front (lay down red paper first, then blue on top) or
front to back (lay down the blue paper first then red on top). If you
drew front to back with a regular engine, the red paper would
completely draw over the blue paper... the image wouldn't look right.
But if all you have is the stuff in the hole, and the stuff outside
the hole, it doesn't matter what roder you draw them in because
there's no overdraw. Doesn't matter if you lay down the little red
square first, or the blue peice of paper with the square hole in it.
So the diffrence is portal engines clip at portals, reducing overdraw
for the 3D card, (but increasing polygon count) and regular engines
draw everything, back to front with lots of overlap.
But like I said earlier, "regular engine" just means a basic simple
engine. There are so many diffrent optimizations you can do to reduce
the overdraw, but with any variation on a non portal engine, there's
probably going to be quite a bit of overdraw, even if you aren't
drawing the ENTIRE world from back to front every frame.
Quatoria
ssw...@NOearthlinkSPAM.net (sswift) wrote:
>>Like in Deus Ex, which you hated for its crappy level design.
>
>Deus EX had sliding glass mirrors?
Yes, Deus Ex had sliding glass mirror doors, which you'd have known,
had you played the game. ;) And my point was, you lambast Deus Ex for
it's level design, then turn around and state that a feature found in
Deus Ex is a sign of creative level design - further illustrating that
your experience with Deus Ex was limited to the statue of liberty.
Courtney Evans
> Rainer Deyke wrote:
>
> > "Eep²" <e...@tnlc.com> wrote in message news:3995F37C...@tnlc.com...
> > > Well then Unreal has REALLY big portals then. But just because a game's
> > levels has high cliffs/walls doesn't make it a portal engine. While the
> > other game engines I mentioned tend to have more expansive levels/worlds,
> > they could also have high cliffs/walls to simulate a portal engine.
> > >
> >
> > Whether or not an engine has high cliffs/walls has nothing to with whether
> > or not it is a portal engine. The term "portal engine" refers to the
> > internal technology - you can't see whether an engine is a portal engine or
> > not just by looking at its output.
>
> Not implicitly, but it's common (if not standard) in portal engine
levels to use high cliffs and walls.
It's also common to see high cliffs and walls in outdoorsy levels built in
BSP/PVS engines. It's just a fact of life in building stuff for realtime
display... polycount matters, and high walls and cliffs are the best way
to cut off views.
--
Courtney Evans
My email address is my first name. The domain name is my
last name, followed by the three letters inc, followed by
dot com.
Courtney Evans
<jsm16N...@cornell.edu.invalid> wrote:
<snip>
Excellent explanation.
Courtney Evans
<e...@tnlc.com> wrote:
> Courtney Evans wrote:
>
> > In article <3996A05A...@tnlc.com>, =?iso-8859-1?Q?Eep=B2?=
> > <e...@tnlc.com> wrote:
> > > Not implicitly, but it's common (if not standard) in portal engine
> > levels to use high cliffs and walls.
> >
> > It's also common to see high cliffs and walls in outdoorsy levels built in
> > BSP/PVS engines. It's just a fact of life in building stuff for realtime
> > display... polycount matters, and high walls and cliffs are the best way
> > to cut off views.
>
> Got some game examples with non-portal engines that use BSPs and PVSes
(?) with high cliffs/walls? I thought all portal engines used BSPs...
Half-Life, anytime you go outside you're down in a canyon, or on a
cliffside with nothing but a skybox on one side.
Eep²
> In article <39977624...@tnlc.com>, =?iso-8859-1?Q?Eep=B2?=
> <e...@tnlc.com> wrote:
>
> > Courtney Evans wrote:
> >
> > > In article <3996A05A...@tnlc.com>, =?iso-8859-1?Q?Eep=B2?=
> > > <e...@tnlc.com> wrote:
>
> > > > Not implicitly, but it's common (if not standard) in portal engine
> > > levels to use high cliffs and walls.
> > >
> > > It's also common to see high cliffs and walls in outdoorsy levels built in
> > > BSP/PVS engines. It's just a fact of life in building stuff for realtime
> > > display... polycount matters, and high walls and cliffs are the best way
> > > to cut off views.
> >
> > Got some game examples with non-portal engines that use BSPs and PVSes
> (?) with high cliffs/walls? I thought all portal engines used BSPs...
>
> Half-Life, anytime you go outside you're down in a canyon, or on a
> cliffside with nothing but a skybox on one side.
Half-Life is based off the Quake 2 engine which is a portal BSP engine, I believe.
mr bernard langham
> Half-Life is based off the Quake 2 engine which is a portal BSP engine, I
believe.
>
I could be wrong, but I don't think the Quake 2 engine used portals. If so,
we would have seen a lot of "magic mirror/gateway to another plane" gimmicks
in Q2.
Eep²
sswift
>In the swirling mists of history, on Mon, 14 Aug 2000 00:01:09 GMT,
>ssw...@NOearthlinkSPAM.net (sswift) wrote:
>
>>>Like in Deus Ex, which you hated for its crappy level design.
>>
>>Deus EX had sliding glass mirrors?
>
>Yes, Deus Ex had sliding glass mirror doors, which you'd have known,
>had you played the game. ;) And my point was, you lambast Deus Ex for
>it's level design, then turn around and state that a feature found in
>Deus Ex is a sign of creative level design - further illustrating that
>your experience with Deus Ex was limited to the statue of liberty.
I said it was creative because 99% of level designers, including the
guys who made the game never figured out how to do something like
that.
That's not the case with Unreal, I'm sure. :) So I'm afraid that the
Deus Ex guys aren't all the creative because they did it in that
engine... it was easy for them to do.
sswift
>>Of course, few engines are purely portal based or purely PVS or
>>whatever based. The Quake engines for example support portals,
>but
>>the level designer needs to place them where they want them...
>So they
>>can make sure they go in the areas that will help most and they
>won't
>>show up everywhere and slow everything else down.
>
>Hmmm...I would have guessed that was how every portal based
>system works.
No way. :)
>I guess in a "pure" portal based engine every cell
>must be convex, but I doubt if anyone really does things this
>way. For some levels it might make sense just to have each cell
>be one half of the entire level, with one portal in some
>corridor connecting them.
I'm pretty sure, but not positive, that Thief/SS2 used a relatively
pure portal based engine. I didn't work on any of the code for the
engine, but from what I gathered from doing level design with the
engine, even a simple room with a cube in the middle of it would
generate tons of portals.
I believe they were carving the world into convex areas, and then
rendering all of them with portals leading to adjacent areas.
As you can imagine, a simple cube room with a cube in the middle of it
would carve the room up quite a bit, and require quite a few portals
to render if each seprate concave area had to have one or more portals
leading out of it.
There was even a mode you could turn on where you could see the
"cells" the engine was generating with vector lines inside the
polygonal world showing how it was split up.
Needless to say, the engine was very slow at rendering detailed
geometry because of all the portals.
We got around this limitation in System Shock 2 by filling most of the
rooms with objects instead. Objects like chairs and tables and plants
and such were just placed into the world, and didn't generate
portals... So we could put tons of those without slowing the engine
down.
Was it a good idea to have such a purely portal based engine? I don't
think so... I think hybrid engines are better. Especially when you
don't really put portals to their best use... allowing lots of
moveable geometry. Thief had almost no ability to move world geometry
around, and I'm pretty sure it didn't even support mirrors.
I did like the engine though, mainly because of it's "solid" world
arhcitecture. Like Unreal, you coule carve a room out with a single
brush.
sswift
>
>> Half-Life is based off the Quake 2 engine which is a portal BSP engine, I
>believe.
>
>I could be wrong, but I don't think the Quake 2 engine used portals. If so,
>we would have seen a lot of "magic mirror/gateway to another plane" gimmicks
>in Q2.
Oh there were...
Like in the Jail level... You'd often walk around a corner and see
that "magical" HOM effect. :)
But seriously... that did happen, and it was because of portals.
Quake 2 had limited portal support to help the engine figure out what
was visible. It just couldn't do the neat stuff with them that Unreal
does.
sswift
>Well, if Quake 2 wasn't a portal engine, Half-Life was, which used a modified Quake 2 engine.
Quake 2 did have portals.
Portals aren't the reason for those high canyon walls either.
High canyon walls allow you to attach the wall to the sky without the
player noticing. And when you can connect stuff to the sky, you
create a "hallway" like construct. The way Quake's engine went so
fast was by using hallways... When you had a long hall with something
like a 90 degree turn in it, and the engine tried to do visibility
calculations on a room off it, the visibility checker would get to the
hall and not be able to see around the corner into the next detaield
room.
You couldn't make a big city in the Quake engine, because it wouldn't
be able to do a good job of determining what was visible from where...
especially if the tops of the buildings didn't touch the sky... it
would assume you could see over them.
So all those big canyons in Half-Life are are just big hallways
diguised as canyons to lead you to the next area.
mr bernard langham
"sswift" <ssw...@NOearthlinkSPAM.net> wrote in message
news:3999d7c3...@news.earthlink.net...
> "mr bernard langham" <blu...@diespamdie.ii.net> wrote:
> >
> >> Half-Life is based off the Quake 2 engine which is a portal BSP engine,
I
> >believe.
> >
> >I could be wrong, but I don't think the Quake 2 engine used portals. If
so,
> >we would have seen a lot of "magic mirror/gateway to another plane"
gimmicks
> >in Q2.
>
> Oh there were...
>
> Like in the Jail level... You'd often walk around a corner and see
> that "magical" HOM effect. :)
Heh.
mr bernard langham
"sswift" <ssw...@NOearthlinkSPAM.net> wrote in message
> We got around this limitation in System Shock 2 by filling most of the
> rooms with objects instead. Objects like chairs and tables and plants
> and such were just placed into the world, and didn't generate
> portals... So we could put tons of those without slowing the engine
> down.
That was one of the nicest things about SS2, in terms of level design
anyway -- the number of prefabs per room. I remember Ridley Scott saying
that, when building the bridge set for the Nostromo, he had the dressers
load in bucketload after bucketload of old WWII bomber bits-n-pieces, and
when they reached a certain critical mass, it looked *real*. SS2 achieved
the same effect, IMO.
>^..^<
Bernard
--
mr bernard langham . blueboy@(diespamdie)ii.net . perth, western ashtraylia
cassetteNET/DIY lo-fi punkarama/indie vs major FAQ http://ii.net/~blueboy
--
"Feel free to cite, sample, steal, sell, reference, borrow or plagiarize
anything that I have created, thought or said. Information wants to be free
and intellectual property is both anachronistic and wrong" -- Meme #96
Hansjörg Malthaner
Eep˛ wrote:
> Rainer Deyke wrote:
>
> > Whether or not an engine has high cliffs/walls has nothing to with whether
> > or not it is a portal engine. The term "portal engine" refers to the
> > internal technology - you can't see whether an engine is a portal engine or
> > not just by looking at its output.
>
> Not implicitly, but it's common (if not standard) in portal engine levels to use high cliffs and walls.
Sorry Eep,
I may be a nonstandard programmer but I use portals in my doom-style raycasting engine. No high walls or
even cliffs there.
c.u.
Hajo
Chris Carollo
> A portal engine on the other hand cuts the "paper" (polygons) like I
> described above. Because it does that, it doesn't even matter if you
> draw back to front (lay down red paper first, then blue on top) or
> front to back (lay down the blue paper first then red on top). If you
> drew front to back with a regular engine, the red paper would
> completely draw over the blue paper... the image wouldn't look right.
Well, assuming you're not using a z-buffer, and all current 3d
cards use a z-buffer for drawing, so both types of engines on
today's hardware would end up with identical output.
Also, most "portal" engines don't do an exact cut along silhouette
edges -- they just roughly do visibility culling based on portals.
-Chris
sswift
>sswift wrote:
>> A portal engine on the other hand cuts the "paper" (polygons) like I
>> described above. Because it does that, it doesn't even matter if you
>> draw back to front (lay down red paper first, then blue on top) or
>> front to back (lay down the blue paper first then red on top). If you
>> drew front to back with a regular engine, the red paper would
>> completely draw over the blue paper... the image wouldn't look right.
>
>Well, assuming you're not using a z-buffer, and all current 3d
>cards use a z-buffer for drawing, so both types of engines on
>today's hardware would end up with identical output.
Well, yes... But I can't exactly describe the output of every single
possible combination of engine features. :)
>Also, most "portal" engines don't do an exact cut along silhouette
>edges -- they just roughly do visibility culling based on portals.
Okay okay... but I was talking a "pure" portal engine. No zbuffer, no
cheating. :)
Courtney Evans
<e...@tnlc.com> wrote:
> Half-Life is based off the Quake 2 engine which is a portal BSP engine,
I believe.
Half-Life is a highly modified Quake 1 engine, with a few bits of Quake 2
thrown in here and there. It uses a precalculated PVS system for
visibility, and is not an explicity 'portal' engine. (IE, in building
maps, you don't put portals in to manage visibility, you let the vis
program seperate the map into leaves in a visibility tree. This may often
work like a portal engine, in that the seperation between leaves happens
at convenient spots like windows, doorways, and corners, but it's not the
same as a purely portal-based engine.)
Eep²
Sorry, Hans, but "Doom-style" IS walls and portals.
Peter Cowderoy/PSYCHO
Could someone quote this for me?
Eep² <e...@tnlc.com> wrote in message news:3998ECF8...@tnlc.com...
> Sorry, Hans, but "Doom-style" IS walls and portals.
>
No it isn't. You don't know what you're talking about or you wouldn't be
asking here so FFS stop being so fuckwitted!
For your ignorant benefit, Doom was another BSP engine.
--------------------------------------------------
psy...@cowderoy.co.uk
'In Ankh-Morpork even the shit have a street to itself...
Truly this is a land of opportunity.' - Detritus, Men at Arms
Hansjörg Malthaner
Peter Cowderoy/PSYCHO wrote:
> Could someone quote this for me?
>
> Eep² <e...@tnlc.com> wrote in message news:3998ECF8...@tnlc.com...
> > Sorry, Hans, but "Doom-style" IS walls and portals.
>
> No it isn't. You don't know what you're talking about or you wouldn't be
> asking here so FFS stop being so fuckwitted!
>
> For your ignorant benefit, Doom was another BSP engine.
I used the wrong words, I'd like to say my engine uses
four degrees of freedom like DOOM did and
replaces BSPs with portals, since portals fit very good
into a raycasting engine.
I see I'm not ready to argue with Eep yet ...
c.u.
Hajo
Peter Cowderoy/PSYCHO
Hansjörg Malthaner <hansjoerg...@danet.de> wrote in message
news:399AA329...@danet.de...
Yeah, no knock intended on you :-) I know what you meant, and what you said
was perfectly valid. The bile was all aimed at The Usual Suspect.
> I see I'm not ready to argue with Eep yet ...
>
Heh :-)