swd3dm2 - never outgunned

(swelt) #1

swd3dm2 beta 5 (742k)

:skull:

(Zombie13) #2

Hey thatā€™s a pretty neat layout, pretty cool to bounce around in as well :slight_smile:

Z

(Wils) #3

Nice layout. I like the megasphere/RL bit, reminds me a little of DM4 :slight_smile:

Couple of problems I can see developing:

  1. Your ceilings are a little low - it might be smoother to navigate if you bump them all up 16-32 units or so.
  2. The mapā€™s so open that a lot of the portals arenā€™t doing anything because the game thinks theyā€™re visible from both sides, so youā€™re potentially limiting the amount of detail/lighting you an add if you want to keep framerates high.
(swelt) #4

Ta for the comments.

On the portalling thing, I wonder if this is because of the shape of the map, or whether itā€™s because Iā€™ve placed the portals badly? Iā€™m putting them flush with obvious doorways and such, but would I be better placing them tucked away or at angles? Iā€™ve not seen any portal tutorials that explain how they should be placed in more complex structures than room-corridor-room. I was never much good at hinting in Q3 either :slight_smile:

(Loffy) #5

Hi!
Cool screenshot! Was it hard to learn mapping in doom3?
I see these screens and I read about the happy mappers that map in doom3 atm. My wish-lish:

  1. Freetime 6 months, to map doom3 mp maps.
  2. Peace on earth.
  3. More freetime, so I could create and release cool single-player levels for doom3.
  4. Cure for cancer.
  5. I win lots of cash on lottery.

// L.

(Wils) #6

Maybe a quick explanation of how portals work would helpā€¦

In slightly simplistic terms, Doom 3 chops the world into areas using the portals you place, and draws everything in each area as one model. It knows to draw an area if it thinks you can see that area, and it works that out by doing a cheap 2D comparison in your screen space to see which portals overlap.

An easy way to think of portals is to imagine them as doors in a house - if youā€™re in a room, and you can see a door, two possibilities emerge: either the door is closed, and you canā€™t see the room beyond, or the door is open, and you can. If you position yourself so that you canā€™t see the door in the first place, itā€™s even easier - whether itā€™s open or closed, thereā€™s no way you can see into the room beyond.

This extends into multiple rooms quite logically - imagine there are three rooms: A, B and C. Youā€™re in room A. Room A has a doorway into room B, which has a door leading into room C. All the doors are open.

If you position yourself in room A such that you can see the door into room B, the game will draw all of room B (it actually wonā€™t draw all of it, but more on this in a second), including the doorway from room B into room C. Because it knows thereā€™s a door in room B into room C, and it knows you can see into room B, it checks to determine if you can also see into room C. It does this by looking to see if any part of the door into room C falls inside the visible area of the door into room B - in other words, can you see the door into room C from your current position? If you can, it draws room C, if not, it doesnā€™t.

Portals also do one other major thing - going back to the room/doorway example again:

If you look through a door into a room, you can only see so much of that room. The part you can see is bounded by the door frame - if you project that frame away from you into the room, the shape it makes will roughly correspond to the parts of the room you can see. Now (just to be difficult), imagine the view of the room is a picture, and the door frame is a frame youā€™ve placed on top of the picture. If you were to cut out the whole picture around that frame, leaving just the part inside, the part you can see would look exactly the same. Thatā€™s essentially what Doom 3 does to save drawing all the geometry outside the bounds of your portal.

Bear in mind my understanding of portals is as a level designer, not a coder, but the above load of crap works for me, so you might find it useful :slight_smile:

(swelt) #7

@Loffy: Iā€™ve been mapping in Q3 for a few years and have made around 20 maps, the fundementals are the same so the transition is failry quick. Iā€™ve still got plenty to learn, but Iā€™ve always tended towards functional over detailed due to the amount of time and effort I can commit to a hobby.

@Wils: Thanks. I think Iā€™ll digest that, then perhaps come back with some specific questions.

(def46) #8

Try r_showPortals 1, illustrates what Wils said very well (try with the stock MP maps)

(swelt) #9

Iā€™ve played around with portals a bit and uploaded a new alpha to the same URL. I think itā€™s an improvement, but in a number of places I seem to be seeing alot more portals than I think Iā€™d like. Any suggestions or examples of where something could be portalled more efficiently? Is it just a case that I havenā€™t paid enough attention to vis when forming the structure (always a problem when you put gameplay firstā€¦?)

That given, Iā€™m also seeing something rgoer has mentioned before: that toggling r_showtris 2/3 and r_usescissor 0/1 gives interesting results. Is this related to your last example or is the scissor process something else? It looks to me that, though the portals indicate I should be generating a lot of overdraw, the tris still arenā€™t being drawn.

Misc things:
Is there any guidance on how many portals is too many? I noted that portal causes extra tris to be generated (logical after thinking about it). Any other factors with using lots of portals?
Can you have horizontal portals? I tried adding some but they didnā€™t seem to have any effect or appear with r_showportals
Iā€™ve not really looked at the stock maps for portal usage as the single player structure works quite well with straightforward room-door-corridor. Are there any good examples of complex portal usage in the stock maps?
How does efficient portal placement effect lighting? Is this more of an issue that tris overdraw?

(def46) #10

Yes, the scissor and portals are related. The scissor is a really basic function of every 2d/3d card : it will clip out ANYTHING outside of a specified rectangular area on your 2D screen. The scissor is a 2D clipping that doesnā€™t reduce the overhead of transforming/rotating your 3d polygons, but reduces pixel overdraw similarly to the Z buffer.

The scissor is set for each portal to the extents of the portal AS SEEN on your 2d screen. It is not really necessary because I think the Z buffer would prevent the cut off parts to show anyway, BUT the scissor will save pixel overdraw and there may be a few other technical advantages to it over the zbuffer (i.e. maybe the 3d card can detect if the bounds of a triangle are outside the scissorā€™s recangular area and save some more GPU cycles, but Iā€™;m not sure, the Z buffer on the other hand only works on per pixel basis, look at the depth values).

Effectively scissors OFF + showportals ON will let you see better all the geometry that is transformed/rotated/lit.

Is there any guidance on how many portals is too many? I noted that portal causes extra tris to be generated (logical after thinking about it). Any other factors with using lots of portals?

(edited: yeah, the portals ā€˜sliceā€™ through surroundng brushes and can create extra triangles, just watch for minimizing the cuts) There are some cpu calculations to figure out the visibility from one portal to the ones behind it, based on your view point (the red/green coloring with r_showportals). It also involves setting the scissors for each ā€˜greenā€™ portal before rendering whatā€™s behin (that should be a minor cost).

Can you have horizontal portals? I tried adding some but they didnā€™t seem to have any effect or appear with r_showportals

You mean sitting on the XY plane ? Yes you can. Generally not useful in a large room cut accross its height, since you see everything anyway. But could be useful for really tall rooms, when the doorways leading to such rooms are low, because then from inside the hallways, you can not see the upper part of the main room because of the smaller vis portal between doorway and room. If the upper part of the room has lots of geometry, that could be useful.

How does efficient portal placement effect lighting? Is this more of an issue that tris overdraw?

A polygon is lit the same no matter what. A visportal that stands between a light and a polygon touched by the light, does not affect them. I think the engine looks at the polygon first, not the light. So if you ve got a truckload of polygons culled thanks to visportals, all the lighting that goes with it is also skipped.

I dont understand your second question there. Basically the number of lights hitting polygons, and placement of visportals for culling out areas of the map and reduce overdraw (not so much overdraw as # of polygons pushed on the graphics card), they both are very important.

(MindLink) #11

Those last few answers should be put into a sticky at the top of the forum :slight_smile:

(swelt) #12

Updated alpha, first pass of detail and texture.

(Zombie13) #13

Not looking to bad, if you havenā€™t already decided to do so, might want to break up the use of that orange like texture in the 2nd pic with some trims or what have you, but well underway :slight_smile:

Z

(swelt) #14

Updated to beta status, links and shots updated!

swd3dm2 beta (684k)

ed: updated again after squashing fps blackspot.

(wviperw) #15

Iā€™m getting quite a few black brush faces due to shadowing, even w/ my mp config:

With specular/bump turned off, these faces turn straight black, rather than having small highlights.

Also seem to have an invisible plat at PG.

Iā€™m not so sure about RL->Mega, then RJ up to armor. Seems too powerful. Maybe if you moved the RL outside of the mega area to that room w/ the crates, it wouldnā€™t look so tempting to RJ up through the mega hole. (remember RJā€™s are relatively ā€œlow costā€ in D3 MP)

(swelt) #16

Odd. In my gameplay cfg, that room is really bright. Perhaps youā€™ve got a fkd up setting somewhere? BTW, r_skipspecular always gets turned off for me in MP, are you sure you are supposed to be able to disable it? As it happens, Iā€™ve relit the main rooms in my local copy anyway now and indeed the pg plat. Found that smaller lights using the twopass shader to be much kinder to fps than the oversized lights I had been using.

Regards the RL/MH - I see what you mean, but for a room that only has one non-trick exit and a pit of death, I think the reward needs to be significant. Shifting the RL out into the crate room wouldnā€™t make any difference unless you had spawned in the room (and the spawn in there is not an ā€˜initialā€™ spawn, so that only affects mid-game spawns). I fully expect players to RJ out of the MH room alot, the proximity of RL and RJ spot will only be a factor in learning the importance of that route.

(wviperw) #17

Checked it again. Cranked r_gamma up to 5 and I still had the same black faces. Iā€™ve got r_shadows 0, r_skipbump 1, r_skipspecular 1 in my MP config, and have never had any problems when joining servers. You just have to set it in the actual config (seta), rather than in the console during the game.

(swelt) #18

Updated to beta 2, same URL as above, screens updated.

(swelt) #19

Updated to beta 3, taking onboard some of the output of discussion resulting from the column I wrote on ESReality. Beta 3 now includes barrels and some ā€˜damageable lightsā€™. Unlike the regular shootable lights, these lights ā€˜respawnā€™ after 20 seconds. There are 3 on the top level near the RL/armour. Iā€™ve achieved these lights with a func_damageable and 2 trigger_relays. Iā€™d be interested to know if there were a better/easier way of achieving the same effect.

(swelt) #20

Updated to beta 4 (link @ top of post)

To prevent the chaingun from becoming all powerful: switched position of CG back to original spot, moved CG ammo (also in slightly awkward spot to run), added some pillars to give players a little extra cover.

Also: Fixed damagable lights (werenā€™t working online). Added some glass, pretty much for the hell of it.

1 known problem: the func_fx on the damageable lights only fires the first time in a dedi svr/remote client situation. Works fine on a listen server. Wierd.