Hey, I was wondering how hard it would be to implement sector over sector using special ceiling and floor textures combined with id tags.

RambOrc had similar idea. Currently I have no ideas how to implement this.<br><br>Climbable linedefs - interesting idea.

Something similar was used in Dark Forces as well, they used different levels there. The cool in that one was that you had an automap that could distinguish between levels, you could display only the level you were on, any other level in itself, or all levels at once. AFAIK Build engine games could do only the last of these 3 types.<br><br>Too bad Dark Forces source code isn't out (and probably never will be). <!-- s:( --><img src="{SMILIES_PATH}/icon_sad.gif" alt=":(" title="Sad" /><!-- s:( -->

Well, couldn't it work like the skyboxes?  Its times like this that I wish I could understand more about 3-d programming...I'll try to go with the logic.  We've got a map loaded into memory that the engine renders based on the rules of raycasting.  Since the map data is already in memory, it seems it would be a matter of tweaking the rendering engine.  Lets say we have two sectors, and we give one a celing texture called sector_hole_ceilng.  The second one has a floor texture called sector_hole_floor.  We then set a special id-tag in the sectors, telling the engine that those two sectors are above each other.  Fianlly we modify the renderer code that handles the ceilng and floor textures so that if we are in the first sector looking up and the engine sees that special texture it will actually cast rays into the other sector from the bottom.  (Sorry if my raycasting references are out of place....as I said, my knowledge of 3d rendering is limited.)  Vice versa if we are in the second sector looking down.  The engine will realize that the floor texture is linked with the sector below and cast rays down into it.  In my mind I see it working similarly to the funky effects you see when you accidentally end up in the void outside the map, looking back towards it.  Except in my example here, the engine would be rendering the sector from the top or bottom respectively.  It seems to me that if you can make the engine draw a skybox where a celing texture should go, you should be able to make the engine draw another sector from the map in the same place.<br>To put it another way using my racasting knowledge, the ray travels up from the player at a specific angle and strikes a pixel on our special celing tile.  At this point the engine makes the ray continue into the second sector, starting from the same point on our special floor sector and travelling at the same angle.  It strikes an object in the second sector and the scene is rendered and to the player it looks seamless.  The final touch would be a modification to the movement system so that the player can pass through from one sector to the other and effectively teleport to another part of the 2d map.<br><br>Anyways, let me know if this is possible.

Yes, that can be rendered like this. The thing that you call "final touch" actually is the problem - implementing movement, shooting, sight checking etc.

The first thing I should clear up is that the shapes and sizes of the pass-through sectors should be identical.  This would make ray casting between the sectors much easier as 5x-6y on the celing sector equals 5x-6y on the floor sector.<br>Now, the scene is rendered from the POV of the players eyes right?  That would be a specific map co-ordinate, hight, direction facing, and angle.  There would come a point where the players hight equals the ceiling's hight, and in reality the player would be bumping thier head on our fake celing.  But since we've marked the ceiling as a pass-through, all the engine has to do is change the players map co-ordinates to the other sector, change the player's hight value to the floor, and update the automap.  That takes care of the visual aspect.  Now for the players feet, since he might still have some steps to climb before he passes completely into the other sector.  In this case, another POV is spawned in the original sector at floor level to represent the player's feet.  This POV does not need to be graphically implemented....it only needs to cast rays out to see of the player's feet have bumped into anything.  Once the player's feet POV passes into the other sector, it is released and the game continues like normal.  This feet POV also might make it easier for the engine to detect the player's position in the view of another player.  As far as shooting is concerned....well, isn't shooting just another form of ray casting?  If it is, the bullet ray could pass through our special ceiling/floor texture as easily as a visual ray.  In the reverse, monster ai sight lines could be programmed to pass through and detect the player.  <br>I'm basing my ideas on things I've read about ray casting in a slightly old book on 3d game programming, which told me ray cating was the technology that DOOM and it's clones used.  Please let me know if Vavoom uses some other kind of technology.

About rendering technoligy - Vavoom uses a Quake-based renderer, no rays like in Doom are casted.<br><br>There are no problems with rendering - that's easy. The problem is for example with sight checking. How engine will know that these points are in different map regions, how coordinates must be adjusted, etc. Or should engine convert map to use true 3D BSP tree? Anyway there's no easy way how to implement this. Maybe one day, but not in the nearest future.

Ok, so since it's Quake based, would I be correct to assume that Vavoom builds a 3-d model of the level during level load?  One similar to the kind of level you could make with WorldBuilder?  Also, I'm still confused about sight checking.  Is this similar to the idea of ray casting?  How does the Quake engine determine how far away from the player a wall is?  You asked "[u:uxhbieuy]How engine will know that these points are in different map regions, how coordinates must be adjusted, etc. [/u:uxhbieuy]"  I thought I discussed that....A special ceiling texture in one sector and a special floor texture in another.  Sector type numbers could then be set up in those two sectors, telling the engine on level load that the one with the special floor is on top and the one with the special ceiling is on bottom. If the player looks up and the engine detects the special ceiling texture, it should get a reading from the camera as if it were placed below the TOP sector.  <br><br>At the same time, if one of these ideas worked it would also allow you to make mirrors, since essentially we're talking about getting a view from the camera as if it were outside the room looking in.

Building a 3D model of the level - more or less it does so.<br><br>Sight checking haves nothing to do with ray casting. Two points A and B are given and engine must tell wether A can see B.<br><br>Distance of a point Point from plane (wall, floor, etc) is calculated as:<br><br>    DotProduct(Point, plane->normal) - plane->dist<br><br>where plane->normal is normal vector of the plane and plane->dist is<br><br>    DotProduct(plane->normal, PlanePoint)<br><br>where PlanePoint is any point which belongs to the plane.<br>Mirrors - that's something totally different. Assuming that monsters can't use mirrors this is only a rendering problem and is not too hard, but still haves some aspects.

So you're saying that everything is predetermined?  Augh! <!-- s:( --><img src="{SMILIES_PATH}/icon_sad.gif" alt=":(" title="Sad" /><!-- s:( -->  I really want to help you with Vavoom.  Could you point me to some good sites that explain all of this 3d math?  I know C and C++ already, but I've always been intimidated by 3d math.  It's a hurdle I need to overcome.

A very good reading is Michael Abrash's Graphics Programming Black Book which can be found at [url:1o3tggzn]http://www.ddj.com/documents/s=865/ddj0165f/. Basics of 3D math is covered in chapter 61.<br>

The first thing is basically the same as stacked sectors in ZDoom and are implemented as skyboxes, so it's a duplicate. The second could be done with some ACS scripting.