First one is whether it would be possible to render BUILD level from outside of any sector in the map, or does the BUILD hidden surface removal really require camera to be positioned within a sector? What if I have number of sector to start drawing from, but I want to have camera positioned outside of this one sector. The drawing from my position should work as my direction should be enough to determine walls facing to me and the floors would be clipped by non facing walls, or not ?
Second one is how would you approach splitting the floor and walls at regular intervals. I see that such splits are performed at textures boundaries but they somehow tend to float around in wireframe mode. Every time I tried to hack OpenGL polymost I borked it totally.
Ñuño Martínez at
Re: Polymost BUILD: Rendering outside of the sector & regular splits
etko said at
First one is whether it would be possible to render BUILD level from outside of any sector in the map, or does the BUILD hidden surface removal really require camera to be positioned within a sector? What if I have number of sector to start drawing from, but I want to have camera positioned outside of this one sector. The drawing from my position should work as my direction should be enough to determine walls facing to me and the floors would be clipped by non facing walls, or not ?
As you said, Build/Polymost needs to know the first sector from to start to draw. The editor and games use a function to know this sector using the camera coordinates. That function returns a "fail" value if the camera isn't inside any sector, so it loose the track.
I think your suggestion is similar than this (I haven't the Build sources here and I can't remember the exact name of the functions and parameters ;) )
int OldSectorNum; struct { int SectorNum, X, Y, Z, Angle, Horiz; } Camera;
Remember I haven't access to Build sources now so the function names and parameters are orientative. I didn't try something like this so I'm not sure about the result but I think it will draw infinite ground and ceiling planes and other graphical toys as the well known Hell Of Mirrors. Anyway, You'll never see the whole map this way due the culling system used to cut off the "sectors out of the screen". To get a complete view of the map you must hack the renderer or just write a new one by your own.
etko said at
Second one is how would you approach splitting the floor and walls at regular intervals. I see that such splits are performed at textures boundaries but they somehow tend to float around in wireframe mode. Every time I tried to hack OpenGL polymost I borked it totally.
I didn't understood this. BTW, a wall is just a line and to split a line "at regular intervals" you must apply simple linear algebra. A simple "equation system" (I'm Spanish and I'm not sure how to translate "sistema de ecuaciones" to English) should do the work.
Split the floor is split the sector. To do this you must split the walls and then join the new points with new walls creating new sectors. You must be careful and don't cross other walls. To know if a wall crosses another wall you must apply linear algebra (again). The Build editor includes functions that helps creating new sectors.
Edited by Ñuño Martínez at
Awesoken at
A mirror sector is good example of a sector that is rendered from a camera outside the sector. The original mirror code didn't allow the camera to be outside the sector, forcing the map designer to draw large mirror sectors. I eventually fixed that - and that's why mirror sectors can be small now. Note that when the camera is outside the first sector, parts of the screen will not be drawn - resulting in a hall of mirrors if you don't know what you're doing. If you wish to view the whole map without weird black planes getting in your way, or hall of mirrors, then you really can't take advantage of hidden surface removal. You'll have to draw the whole map brute force.
Why do you want to split walls? Is it for shading? If so, that's going to kill your frame rate. Write a shader script instead ; )
etko at
Maybe I should mention for others I am interested only in OpenGL Polymost.
Thanks Ken, I will look into the mirror code.
I was experimenting with HOM before. It just means that the framebuffer is empty and so it is showing previous frame contents. If I draw something before drawing rooms (like black quad) it will not get overdrawn by the level geometry.
I wanted to ask you Ken too, why, when drawing skybox, you are using Polymost too? When I assign 0 tile to the wall it gets HOM "transparency". This means whatever will be drawn there already (in buffer) won't be cleared. This way you could draw simple skybox using technique similar to one in Kube and assign zero tile to ceiling and optionally to floor parallelograms. You are using some complicated calculations instead to split the ceiling and floor quads where the edges of skycube are. Isn't this a bit inefficient?
Yes I wanted to use lightmaps. I can export the map in OBJ or ASC format and import it into Blender. I could then use then GI or Radiosity to light the level. However for this to work, splits must be there, at minimum after 512 or 1024 world units, because of graphics card texture requirements. I could split the sectors and thus walls manually, but that is counter productive, I am afraid that that would deplete number of free sectors quickly too. Best would be to have auto-split grid. I was thinking along the lines of another set of lightmap tiles in another file accompanying map with precalculated lightmap data.
I have no idea how lightning calculation works, I am unable to use GLSL to do shaders and i don't understand realtime lightning too.
Ñuño Martínez at
etko said at
(...) However for this to work, splits must be there, at minimum after 512 or 1024 world units, because of graphics card texture requirements. (...)
I still don't understand this and I'm curious about it. IIRC the texture size requirements are only to store the texture but not to draw it. I mean, any graphic hardware can repeat the texture if it's needed, as the classic Build engine does.
This will draw a "quad" repeating the texture, which will be drawn four times. I don't understand why you say you "must" split the sector or the walls. May be because Blender (or OBJ or ASC) will use a BSP? Even in that case I don't understand why you "must" do it, Blender should be smart enough to build the BSP itself.
As I've said I'm curious.
Awesoken at
when drawing skybox, you .. split the ceiling and floor quads where the edges of skycube are. Isn't this a bit inefficient?
You are overlooking the main benefit, which is no ovedraw. The extra calculations for polygon clipping shouldn't be too bad in most cases.
Ñuño Martínez at
Awesoken said at
when drawing skybox, you .. split the ceiling and floor quads where the edges of skycube are. Isn't this a bit inefficient?
You are overlooking the main benefit, which is no ovedraw. The extra calculations for polygon clipping shouldn't be too bad in most cases.
Also, the original Build does allow to use different skies on each sector if you want. If Polymost draws the whole skycube as you (etko) suggested it will ruin some interesting effects used by some games (i.e.: Shadow Warrior) because it will not allow to use more than one skybox each map.
etko at
Ok my bad with the skycube, you have valid points. Calculation is probably not that costly, plus there are those effects Ñuño Martínez describes.
Although I think that true 3D skybox overdraw is not that much of a problem. As far as I know modern graphics cards are designed to draw large chunks of polygons in one call, using some kind of buffer for data in their memory, and are probably more optimized for that than for using intermediate mode like Quake 1 and BUILD does. I mean it seems cool for level geometry but might be not that cool for in game 3D models (MD3s), especially high poly. When I turn on shadows in BUILD I experience some frame drops with MD3 models.
Anyway Ñuño Martínez imagine the huge ground of the sector or a long wall. When you use lightmaps you can create any lightning pattern on the wall or floor using offline renderer and using any advanced technique you have at your disposal (radiosity, GI - these generate realistic lightning). The problem is if you have wall say 10 000 world units long and 128 units high, and lightmap pixel has size of one world unit ,there is no way for you to assign texture of 10 000 x 128 pixels to the wall, or there is? Hardware has limits, for the modern one say 512 px for each u or v dimension to be on safe side, so you need to split the ground and wall to 512px patches, to be able to map lightmap texture onto them. Or am I wrong?
Ñuño Martínez at
etko said at
Anyway Ñuño Martínez imagine the huge ground of the sector or a long wall. When you use lightmaps you can create any lightning pattern on the wall or floor using offline renderer and using any advanced technique you have at your disposal (radiosity, GI - these generate realistic lightning). The problem is if you have wall say 10 000 world units long and 128 units high, and lightmap pixel has size of one world unit ,there is no way for you to assign texture of 10 000 x 128 pixels to the wall, or there is? Hardware has limits, for the modern one say 512 px for each u or v dimension to be on safe side, so you need to split the ground and wall to 512px patches, to be able to map lightmap texture onto them. Or am I wrong?
Now I think I've understood it. No, you're not wrong. If the lightmap isn't repeated you have the hardware limit. Anyway I think you would try to increase the lightmap pixel size. It will have less resolution but may work.