## Fw: [Algorithms] Non-euclidean world geometry

 Fw: [Algorithms] Non-euclidean world geometry From: Sergei Miloikov - 2002-04-30 09:39:23 ```----- Original Message ----- From: "Jon Watte" > > > 1. Can somebody point at paper or to suggest something about > > such technique > > > but for rigid bodies, i.e. not only points [...] > > > > I typically put "objects" inside "areas" separated by "portals". Each area > > acts as a container of these objects (and these portals) so that rendering > > an area renders all the objects in that room and all the portals > > to adjacent > > rooms. > > There's an additional poke-through problem when you use "warped" geometry > though. ASCII art time! > > Room 1: > > \ / > \____+ppp+_____/ > > Room 2: > > /\ /\ > / ~~~+ppp+~~ \ > / \ > > If these two room segments (as seen from above) are joined at the "+ppp+" > portals, then the geometry "spikes" of room 2 will poke through the walls > of room 1. This will not happen with "regular" geometry because the Z buffer > will prevent it. A fix for "warped" geometry is to use the stencil buffer, > where you increment the stencil value for each level of recursion, and only > render if the render stencil value is LESS than the stencil buffer value. > Clear stencil to max initially. > > Cheers, Yes, that is a problem, but the major trouble comes from placing buildings over terrain or to caves and underground tunnels which have entries on the terrain surface. The stencil buffer is a solution, but what to do on older cards? Now I'm just planning to use one special terrain feature which replaces regular terrain surface with custom mesh, duplicate terrain surface into that mesh, remove terrain surface, cut the proper hole in the mesh and put the mesh where the terrain surface was. Cheers! ```

 Fw: [Algorithms] Non-euclidean world geometry From: Sergei Miloikov - 2002-04-30 09:27:54 ```----- Original Message ----- > On Mon, 29 Apr 2002 15:31:01 +0300, "Sergei Miloikov" > wrote: > > 1. Can somebody point at paper or to suggest something about such technique > > but for rigid bodies, i.e. not only points [...] > > I typically put "objects" inside "areas" separated by "portals". Each area > acts as a container of these objects (and these portals) so that rendering > an area renders all the objects in that room and all the portals to adjacent > rooms. > That's right objects are inside areas, but my question was about objects split by portals, when you can see an object 'warped' through portal. I.e. if there is an rotation applied by that portal you'll actually see the object twisted by it. This is not the case when portals are simply dividers of your level, but is visible when you have portal in front of you which end behind you (and their normals arent't colinear :). > > 2. The actual data structures and editing all that! Currently I create a > > solid space chunks of geometry sealed with portals and then connect the > > chunks - but this is done from the code, the actual connecting of segments > > may be done by writing my own editor (bad!), besides there is a problem if > > two connected portals' shapes do not fit! And the pure geometrical > > connecting from an editor do not work for the case when you want to put > > bigger volume inside a smaller one. > > As much as I liked the 4D net level of marathon I try to keep my models as > "real" as possible (no imaginary dimensions); All vertices are in world > coordinates; Adjacent areas are separated by portals made up of the same > (not just identical) vertices. Thus adjusting the vertice of a portal in one > area will adjust the same vertice of its mirror portal in the next area > because they are one and the same. Note: individual vertices are loaded, > cached and disposed of whenever my viewpoint (usually the player) changes > areas. The loading mechanism creates an index on the fly that I then use to > pass to OpenGL for rendering or to my physics engine for collision, IK, > etc. and these world vertices are kept separate from my local object > vertices which are also loaded, cached and unloaded as necessary when I > change areas. > > > From the code that is done by assigning IDs to portals and then doing some > > sort of IDx vs IDy connecting with rotation as parameter. So, you can see it > > is not user-friendly at all. > > Your portals need to be much more virtual. Their only real purpose is to > segment your worlds data into smaller chunks so your engines aren't as data > bound. > That's not the idea - dividing the world into smaller chunks is already done, It is cool and the WAY IMHO, for any streaming, scalable FPS engine, but I would like to introduce a transformation to the portals too - main idea is to enclose bigger spaces into smaller ones, which is very cool and extends the idea of teleporters very nicely and without any kind of 'jumping'! Or one can place very small rooms inside a long tubes which pass along the level so it will be... cool..? :) Besides now I create geometry in chunks - if there is no warping portals inside a building then it is made from one chunk (quake .MAP file actually) and then divided into Inner geometry and Outer geometry by hand-placed portals at building doors/windows and so on - then that building can be places over terrain. The division to inner and outer 'skin' is done for LOD purposes - the inner geometry is processed only when a contribution of some of 'inner/outer' portals to the screen is bigger that some constant. > As far as editors go, I'm really tired of "reinventing the wheel". Every > "canned" (off the shelf) editor I've ever used has always fell short on some > feature that I've wanted and "writing my own" has always taken every bit as > much time as writing the game it supposed to be creating levels for. Ouch! > I've "borrowed" editors from other games and "tweaked" them for my use. > Again I seem to spend as much time writing utility apps that take their > (usually illogical, or out-of-order) data and convert it into the format or > order that my games expects. By the time I'm done I've again almost spend > enough time on the editor that I could have written it from scratch. > > Hopefully, your mileage will vary... Considerably! ;-) I don't want to write my own editor, because it will eat my time. The idea was to do some research in VSD and create little cute engine :) Cheers! ```
 Fw: [Algorithms] Non-euclidean world geometry From: Sergei Miloikov - 2002-04-30 09:39:23 ```----- Original Message ----- From: "Jon Watte" > > > 1. Can somebody point at paper or to suggest something about > > such technique > > > but for rigid bodies, i.e. not only points [...] > > > > I typically put "objects" inside "areas" separated by "portals". Each area > > acts as a container of these objects (and these portals) so that rendering > > an area renders all the objects in that room and all the portals > > to adjacent > > rooms. > > There's an additional poke-through problem when you use "warped" geometry > though. ASCII art time! > > Room 1: > > \ / > \____+ppp+_____/ > > Room 2: > > /\ /\ > / ~~~+ppp+~~ \ > / \ > > If these two room segments (as seen from above) are joined at the "+ppp+" > portals, then the geometry "spikes" of room 2 will poke through the walls > of room 1. This will not happen with "regular" geometry because the Z buffer > will prevent it. A fix for "warped" geometry is to use the stencil buffer, > where you increment the stencil value for each level of recursion, and only > render if the render stencil value is LESS than the stencil buffer value. > Clear stencil to max initially. > > Cheers, Yes, that is a problem, but the major trouble comes from placing buildings over terrain or to caves and underground tunnels which have entries on the terrain surface. The stencil buffer is a solution, but what to do on older cards? Now I'm just planning to use one special terrain feature which replaces regular terrain surface with custom mesh, duplicate terrain surface into that mesh, remove terrain surface, cut the proper hole in the mesh and put the mesh where the terrain surface was. Cheers! ```
 RE: [Algorithms] Non-euclidean world geometry From: Jon Watte - 2002-04-30 16:40:41 ```> > will prevent it. A fix for "warped" geometry is to use the > stencil buffer, > Yes, that is a problem, but the major trouble comes from placing buildings > over terrain or to caves and underground tunnels which have entries on the > terrain surface. The stencil buffer is a solution, but what to do on older > cards? Now I'm just planning to use one special terrain feature which You can use only a part of the depth buffer range for each portal cell. If you support a recursion depth of 16, then find the nearest and furthest points of each cell before you draw it, and re-scale the depth mapping so the nearest point of a new portal has a further depth buffer value than the furthest point of the currently drawn cell. This cuts some bits from your available Z precision, which is OK with 24 bit Z, but could be problematic if you only have 16 to start with (collapsing to 12 bits per cell in this scenario) Cheers, / h+ ```