In my experience those sort of differences between tyrutils and txqbsp are usually due to the different default epsilon values the compilers have.

For research purposes: try passing the flag "-epsilon 0.0001" to txqbsp, it should bring back the flickering face. The next version of my tyrutils-ericw will support that "-epsilon" flag so you can tweak it.

However, as ijed says there are probably some off-grid brushes / small misalignments that are the root cause. 

Just gave it a go but no flickering faces that I can find anywhere. Tried snapping vertices too (Ctrl+A and the ctrl removing all the entities. Ouch)

Thanks all though. Giving up for today. I'll make do with the misaligned trim for now. 

I don't really wanna do any wall detailing. but here's some screenshots before the final release:

http://imgur.com/a/GNRJv
-extra4 -dirt -dirtgain 0.5 -dirtmode 1 -light 50

http://www.mediafire.com/download/5qio1p35pvaqe90/shifter_b10.bsp

thanks for the advice on the lighting tools and everyone elses input. 

 

 

https://pbs.twimg.com/media/CRi1hhnWwAAW8P4.png:large 

looks good. I can see some vertex snapping issues in that screenshot on the right hand side. This type of architecture can be difficult to get on grid for sure. 

It's actually on grid in editor but it turns out that way after qbsp. Don't know how to deal with it. 

pulsar: which editor and compiler are you using? make sure you turn off integer planes in TB, this has always been the source of problems for me. 

and same goes for radiant, there is a integer option there as well. 

tho I've got an idea of how to fix this. Though every vertex of these brushes is on grid I have a problem with the shape due to the difference between rear face that can't be seen and face that is actually visible. If I cut of the rear part of each brush , I may solve this problem.

http://clip.corp.mail.ru/clip/m0/1445188735-clip-112kb-b5AsCfnN6ugp.jpg 

I used to get issues like that when I used Worldcraft. 

for something like this it may be better to use pyramid/wedge shaped brushes instead of cuboids. 

vertex being on grid has nothing to do with it.
the plane described by those vertices cannot be represented by an integer, this is the source of the problem.

try using other shapes like fifth is suggesting, also try splitting that square shape into 2 tri faces. (eg: turn 1 brush into 2 brushes each representing half the face). 

necros: I use jackhammer and updated version of aguire's txqbsp.

fifth: Yep, that was the idea I got. I'll try it when I get home.

It's funny that such ideas come not when you're making the actual part, but when you share it. 

paper dog programming! 

Making curvy corridors are always difficult. I tried once but gave up after some time, so well: you made it right, keep it up ! 

Worldcraft/Hammer for some reason lets you use vertex editing to create bullshit impossible brushes that you only notice when your bsp is full of cracks. Primary reason I stopped using Hammer tbh. 

To make curvy things in Quake, it's best to stick with triangles (triangular pyramids in this case).

http://quaketastic.com/files/screen_shots/jam66601.jpg 

http://i.imgur.com/wvXllHm.png 

Also this. 

 

I would just expand the brushes, Pulsar, to close that gap. I wouldnt care too much about intersecting stuff, the compiler works it out in the end.

Unless, of course you want a dibblydeedobbledoo super clean map file, but basically you search for integer solutions for diophantic equations with those curves being snapped to grid.

Ermm yeah, this wont work(as far as my tiny knowledge of this topic is correct..) 

Thats what i wanted to say in the first place!

Quad Post! 

My steps actually curve, the tops are not flat (the corners are not co-planar). Every face on the steps is a separate brush face, not created by BSP chopping up rectangles.

It compiles error and warning free. Also, it was a real pain in the ass to construct.

I left it in my Jam 6 map if anybody wants to look, but I didn't use it because it has serious clipping issues.