QuArK does some things really well.

-I LOVE the interface (how you create and edit things) and could never get into the major brainfuck that are the radiantish editors (Blender is easier...). Not to mention not having a mess of lines but just dots for the grid. So such an interface would get my love.

-All the texture alignment features (apart from locking I think).

-grouping things in folders, also being able to hide those.

The texture browsing is badly implemented, vertex editing is plain horror.

So Vertex editing is what I am after the most. Especially if you could then triangulate for new edges. 

Cameras - all of those. Extras like 'walkthrough mode' and so on are just a waste of time, although a feature I'd like to see is 'mangle readout' so that placing camera entities inside the level becomes easier.

Yeah, texture lock means it doesn't move when you move or rotate the brush - not an easy technical challenge. Changing projection options between local / global is useful as well.

Tagging isn't as useful as it sounds, even though it does seem like you're going for an 'all wads on the HD' approach (which is great). I say this because wads are usually named in a fairly logical fashion - the ones that aren't tend to be not very good. For me such a feature would be an extra. If the texture listing is alphabetical then you're probably good.

Having said that a 'currently used in map' toggle would be good. Worldcraft is a popular editor (I use it as well despite the bugs) which has a very nice texture system - you couldn't go wrong by copying it.

For an entity list remember that it needs to be editable by mappers who may not have any coding knowledge - the simpler the better.

Tabs = win. Especially if they're user editable.

And finally, make everything you can customisable as far as the interface goes. Nobody works the same way, so the easier it is to turn the grid from lines to dots or chocolate drops the better. For example :)

Like with most 3D editors, ease of use and end user customisation options tends to win out over powerful functionality. 

'Worldcraft has a nice texture system' that's only true if you count not having to convert the wads (in 3.3 at least, 1.6a has shitty texturing). 

What will yours do that will set it apart from others? Or is it just a fun personal project to learn programming stuff?

I think strong brush manipulation tools are key for working with large and complex objects - actions like flipping, rotating, scaling are very helpful and save time for the mapper.

Also, it's probably not a must have feature but I really love 3-point clipping. 

What will yours do that will set it apart from others? Or is it just a fun personal project to learn programming stuff?

this is the first thing that came to me mind.

as grahf said, good brush manipulation is a must. rotating groups of brushes by arbitrary angles (with intelligent vertex snapping onto the grid). more powerful automation of texturing over curves (being able to propagate texture alignment as if multiple faces were a single one, for example). mixing between the straight forward regioning of gtkr and vis groups of WC.

basically this late in the game, it'd take a lot to make me switch editors. 

I have always wanted to create a mapping program, but the interface bits is my more immediate concern.

I would like to get this to a level of making maps for Nexiuz.

I also would like to model the editor to be more like Wings3D, where there are commands that can be done on vertex, edge, face, object.

And concerning the convex nature of brushes I would like to be able store a complex brush while editing that gets decomposed as multiple brushes when saving to a .map files.
That should solve many problems with brush editing I think. treating it like a 3d model rather than a convex object.

for curve texturing, that sounds possible with the internal representation of the brush I have decided to use. And it annoyed me as a mapper that I had to manually adjust texture offsets to get them to match.

This is not the best time for me to start a project (getting married in a month and I travel alot) but this will defiantly sustain my attention. 

"And concerning the convex nature of brushes I would like to be able store a complex brush while editing that gets decomposed as multiple brushes when saving to a .map files.
That should solve many problems with brush editing I think. treating it like a 3d model rather than a convex object."

This is something that I wanted to do for ToeTag but, brother, it's a bitch. If you can get it working it'll be great but I haven't found a nice, reliable way to break down meshes into convex chunks yet.

Although I haven't tried my octree idea yet... that one had promise. 

In fact, if you've got a handle on things like how to do texture locking and breaking down meshes and that sort of math in general - we should get together and maybe do a cross platform version of ToeTag or something. 

concave, not convex, right?
That feature would be a true killer feature. 

dunno if this is what you mean, but it would be awesome if you essentially build a 3d mesh out of n-sided polys just like in 3ds max and the editor would automatically split ngons into tris. afterwards, it would look at the face normal and whichever direction is closest, north, south, east or west, it would simply extrude the face backwards, keeping it parallel.
ie: you make a collection of faces that face upwards, it would extrude the face down allowing you to make cool trisouped terrain easily. the same could be applied for caves. 

Madfox looks very nice the frogman :) 

Type of advanced brush treatment you're describing isn't in any bsp editor I've seen (anyone else?) so if you need testing then let me know.

I'm pretty busy so testing to destruction I probably can't do, be an update a week wouldn't be a problem. 

http://groups.google.com/group/maperl 

 

Yeah, all the mappers are here. :) 

all editors are there....

preach, you've got email. 

Does Toetag work in Linux, since Apple's current operating system is mostly Unix based ? 

Would using a GPU for VIS be a possible (and sensible) idea? 

"Does Toetag work in Linux, since Apple's current operating system is mostly Unix based ?"

No, it heavily relies on Cocoa and Objective-C. The underlying OS isn't really a factor. 

Radiant is probably your best bet, either the venerable GTKRadiant or the somewhat newer fork NetRadiant. 

What went wrong with your building outside the limits experiment? I don't remember :P

I'm thinking of a similar sort of thing, a brushwork skybox. 

99.60% and it takes longer than forever even on a quad core machine. At this rate, I estimate it will be done in around five days. However, the problem is that I will be out of town for a month tomorrow (I'll still have a computer available, but a slow one).
So, does anyone here by chance have a really fast machine and is willing to help me out? Willem, that 16 core thing of yours - would it be possible to use it for this or is it only for work stuff? 

ijed: absolutely nothing! you can build outside the +/-4096^3 playable area to your heart's content, just don't ever let the player walk past that boundary because they 'loop' back to the opposite side of the map (like in pac-man) but the collision behaves as if you hadn't looped back.
also, don't let the player shoot projectiles past the boundary because they loop back too. if this is for RQ, it would be a good idea to place triggers along those boundaries to remove projectiles.
also, as a side-effect to this looping, you can't place any point entities outside the boundary, but bmodel entities are ok.

there is a hard limit though. you can't build past +/- 8192. anything beyond that doesn't get displayed at all. in fitzquake, it looks like you have farclip on-- it's just cut off at that point and you see the void (or hom).

this behaviour is attributed to the fact that the coordinate system of the server runs on variables twice as large as that of the client. 

Play russian roulette: Set up a script that zips and uploads the file in 120 hours, then shutdown the pc. 

negke

I could try and run it but it IS a work machine. I can't tie it up endlessly with a VIS process...