But it's only the plane-definition triangle that would have it's points snapped to grid, so it won't matter how many points there are in the face/winding ( see czg's post ). 

ricky - you can't make invalid planes just by altering the plane coords, and you won't make an invalid brush with such a tiny amount of snapping unless the brush is basically degenerate already. 

What if the snapped plane coordinate cannot be represented as a floating point number? I'm still a bit confused by floats, to be honest. Also, where did you get this idea? Does any editor do this kind of snapping? 

but surely any multiple of 0.125 within a realistic range (ie a range of values you'd find in a quake map) can be represented perfectly in floating point unless im missing somthing? 

With standard single precision, you have 23 bits of mantissa, so if you stick to 1/8 precision you will use 3 bits for the fractional coordinate and you have 20 bits left. Which means that any coordinate on the 1/8 grid will have a precise floating point representation with the coordinate range +/- 2^20 (1048576).

I'm not aware of any other editors that snap to a fractional grid, but I do remember looking at a version of radiant some time ago and seeing the code which always snapped their plane points to integers. 

Well I have an algorithm that will find quasi-optimal integer points for any given plane, but even then it doesn't work too well. I could try snapping to .125 or an even lower value and see how that goes. 

Yeah, that only says how precise the final representation can be. You may (and probably will) need extra precision for intermediate calculations. It's tricky stuff! 

The Doom3 editor supports 0.5, 0.25, and 0.125 grids. 

I can add that to TB in a jiffy, but the major problem right now is how to represent the planes with maximum precision across file saves. 

One option, and you probably don't want to do this, is to go the Worldcraft route. Store maps in your own format and export to MAP for compilation. That would retain perfect precision at all times and only need to snap once, eliminating drift. 

Of course, but it does show that even id ( and JC ) are fine with that kind of granularity.

And as others have stated already, certain fractional steps ( 0.5, 0.25, 0.125, 0.0625 ... ) should not cause rounding errors - as long as the absolute value "in front of the dot" is not too large.

This page is pretty handy to see whats going on : http://www.h-schmidt.net/FloatConverter/ 

If you limit the plane point coordinate precision, you will be unable to snap vertices to the grid in certain situations. 

It will eliminate drift, yes, but it leaves the problem of finding good representations of your brushes when exporting the map file. You must remember that TB will also support games like Hexen 2, where floating point compatible compilers are not available. I think it's better that the user actually sees what the geometry will look like to the compiler. 

But it would mean you don't have to use integers, but could use certain fractions of floats for your drift-free plane definitions - which could mean more accuracy to what the user intends - or am i seeing this wrong ? 

Sorry if I sound like an idiot for asking, but if a brush is just a collection of planes at a certain vector how can they even become degenerate? Convexity? 

But if you limit the precision of the plane points, you limit the number of points where a vertex can be because not every plane can be represented with limited-precision plane points. As the easiest case, think of a plane that is parallel to the XY plane with a Z value of 0.4. This plane cannot be represented with integer precision plane points. The closest approximation is the XY plane itself.

The problem is that it is impossible to represent the many brushes which can be created with TB's vertex editing (or arbitrary rotation, for that matter) if you limit the precision of plane points. Of course, the smaller the value you snap the points to, the smaller the errors will become.

In any case, I feel the best way is to leave this to the user. I will add a setting to the map properties dialog that will allow the user to choose between integer coordinates and floating point coordinates, and to increase the maximum number of digits written to the map file to a really high value so that the rounding will be minimal. 

That would help me a lot, without me having to learn a new editor. 

 

I made a little tutorial about how to make logic gates in Quake. Currently I just wrote a text file and made an example map, but I plan to put a page on the wiki when I have some better pictures to use :)

http://www.quaketastic.com/upload/files/misc/tutorial_logic.zip

It shows how to make AND, OR and IF ELSE. Using these as building blocks you can do all kinds of things (if else is actually two gates inverse of each other anyway).

What I didn't explain is that the single door logic gate is essentially a NOT gate. 

I'm sure there'll be many cool puzzles coming out of this. 

Hi guys, I just wanted to give this editor a try and read the docu but I don't have any textures loaded.
I am using DarkPlaces and chose the DarkPlace folder for my directory with the Quake stuff in it.
But I don't see any textures being loaded, what am I doing wrong <.< 

which editor?? trenchbroom?

edit > map properties > + button > find your .wad file 

need to download the .wad files.

https://www.quaddicted.com/files/wads/id.wad.zip <--- the standard textures

There's a lot of different texture .wads in that directory too, they *should* all be quake 1 .wads 

you very much!

I used to make maps for Doom and thought that wads are in the main directory like DOOM2.wad (also because of the Quake.wad mentioned in the documentation ^^).

And I know this is a different topic, but can I also make maps for the Q1 expansions like SoA or DoE somehow? I'd love to make use of the entities featured in those games.