Jump to content
Sign in to follow this  
chronokun

circlemap - arena of circular death

Recommended Posts

I'd like to be able to create that level of smoothness in regular maps. Was it difficult to get the shapes right, or do you have a method?

I wrote a function to generate tetrahedral brushes from triangles and with that a program that writes them to a text file and then copy-pasta them into the .map file. I will probably extend it to make a .obj to brush converter but right now it's pretty primitive.

Here's the source code in-case you wanted to take a look:

https://www.dropbox.com/s/tsi24lvadggihnj/ReflexBrushTest.zip?dl=0

Share this post


Link to post
Share on other sites

Oh yikes, I have no idea what to do with that. I have no knowledge of programming, so this is way out of my league.

Yeah, don't worry it's not exactly a usable/useful program anyway, just a quick little test to see how things work before attempting anything more ambitious like a stand alone map editor or tool for converting meshes to brushes for doing more complex maps or something like that. The map was really just a proof of concept to try it out. :)

Share this post


Link to post
Share on other sites

This would be great for when we get multi selection of brushes. I know you say it was a test but will come in handy in the future.

 

I did try to do a spiral stair case but after 4 hours of trying it I settled for a semi circle broken looking stair case :). from the screenshot it looks like you did it with one up one down i tried with just all the same going in the same direction IE: made a sq brush got rid of 2 verts and streched up, copy pasted and then by eye tried to line up so it curvered

Share this post


Link to post
Share on other sites

Using floating point coordinates, how very evil ;)... I am astounded that one sees no gaps... but then again I did all my mapping on engines that need their maps to be "watertight" and using floats would normally be an issue. But this is really amazing. Very cool demo.

Share this post


Link to post
Share on other sites

Using floating point coordinates, how very evil ;)... I am astounded that one sees no gaps... but then again I did all my mapping on engines that need their maps to be "watertight" and using floats would normally be an issue. But this is really amazing. Very cool demo.

Keeping things watertight still seems to pay off in reflex for preventing lightmap leaking, but as edges are properly paired so that they have the same vertex coordinates it should be fine.

ie. don't do this:

xFkqQJM.jpg

The split between the red and blue walls meets halfway along an edge on the floor and ceiling so you have 2 edges meeting 1 edge and so you'll end up with leaks and visible sparkles however if you split the other brushes to match or join the red and blue brush the problem will go away as the edge is defined by numerically identical vertices and will compute the same for both brushes leaving no gaps.

more like this:

gxrGKIK.jpg

 Here the edges are paired and there is no leaking. Same deal as avoiding cracks in tessellation :)

examples of what happens after building lightmaps in each situation (note second image has no leaks):

http://imgur.com/rltatwT,F5kYKlQ,lgBSoFu

Share this post


Link to post
Share on other sites

chronokun,

 

you are talking about T-junctions... and in Q3A that only was a problem when connecting brushes and patches. Not properly fixing it back then caused sparklies. And I have seen the latter in my Reflex map... rightly so probably. Between brushes is really bad though.

 

But that T-junctions are an issue for brushes and light leaks I find strange. I am seeing it on the edges of my ramps where I angled the wall brush to exactly follow the angle of the ramp in corridors. In the cases where the number of touching vertices does not match is probably happening all over the place and I have such cases. Interesting info... will look into it and see if I can unleak a few areas this way. But as a general issue IMO this cannot be the main cause for light leaks, since they would then be all over the place.

 

IMO, angled brushes per se are evil in Reflex... and T-junctions make the issue worse.

 

And this is where mitering comes into play... miter to avoid adding new T-junctions.

Share this post


Link to post
Share on other sites

chronokun,

 

you are talking about T-junctions... and in Q3A that only was a problem when connecting brushes and patches. Not properly fixing it back then caused sparklies. And I have seen the latter in my Reflex map... rightly so probably. Between brushes is really bad though.

 

But that T-junctions are an issue for brushes and light leaks I find strange. I am seeing it on the edges of my ramps where I angled the wall brush to exactly follow the angle of the ramp in corridors. In the cases where the number of touching vertices does not match is probably happening all over the place and I have such cases. Interesting info... will look into it and see if I can unleak a few areas this way. But as a general issue IMO this cannot be the main cause for light leaks, since they would then be all over the place.

 

IMO, angled brushes per se are evil in Reflex... and T-junctions make the issue worse.

 

And this is where mitering comes into play... miter to avoid adding new T-junctions.

Yes, T-Junctions, that was the word I was looking for that would have made that whole post a lot shorter and simpler haha I don't know if that's the only cause or not but it did seem to make a difference and avoid sparklies.

As a practical matter however I think it might end up being very difficult to avoid T-junctions as you have to do a lot of brush splitting as your map grows in complexity but if you keep it in mind as you go and miter properly the mitering should help take care of any T-junctions you miss and join corridors and things with diagonal joins in favour of T-junctions I guess it can still help a lot, although might make texturing harder.

 

 

you are talking about T-junctions... and in Q3A that only was a problem when connecting brushes and patches. Not properly fixing it back then caused sparklies. And I have seen the latter in my Reflex map... rightly so probably. Between brushes is really bad though.

The reason it isn't a problem in Q3A is because it's solved by the BSP compiler doing the splitting I talk about automatically as part of its CSG-Union/Polygon Clipping so the resulting mesh (which is whats left in the BSP file for the renderer to use) actually has properly paired edges, it's basically polygon soup at the end but it keeps all the texture coordinates aligned as they were so you don't really see it without a wireframe view.

Share this post


Link to post
Share on other sites

Yeah... after thinking about it some time it also occurred to me that the bsp compile under Q3A fixes such things... thus we started to miter since the compile only did 90° (or maybe axis parallel might be better worded) cuts when creating new "matching" vertices.

 

I then remembered that a wire-frame-view mode like in Q3A would really help in Reflex to see what happens to brushes. I suspect exactly nothing, i.e. each rectangular face is turned into two triangles and that is it. And I also suspect that no vertex "matching" is done at all, i.e. each brush is treated pretty much as a separate entity not caring about adjacent vertices... thus the required manual approach.

 

It would also be interesting to see "through walls", to check if the engine does any form of portalling or other vis related tricks. I suspect it does not, and that surprises me since the maps still run so fast.

 

All speculation on my part obviously. Just mildly curious.

Share this post


Link to post
Share on other sites

It would also be interesting to see "through walls", to check if the engine does any form of portalling or other vis related tricks. I suspect it does not, and that surprises me since the maps still run so fast.

 

All speculation on my part obviously. Just mildly curious.

Yeah, I'd be surprised if there is any kind of portal based or sector based culling since the maps aren't sealed, they might do some kinds of occlusion culling and frustum culling but who knows, it'll be interesting to see how they approach map/vis optimization stuff as the game develops for sure. Kinda curious how the collision detection is done too =)

Share this post


Link to post
Share on other sites

We're surprised this actually runs.

 

GG shootermans. 

 

The light leaks are not really worth chasing right now -- you may as well just wait for us to fix them and then rebuild your lightmap.

 

I think the only culling we do right now is frustrum (there is a TON more we can do but it takes time).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×