Layers support in Radiant?

[toneddu2000]

Hello guys, I was wondering if exists a qeradiant compliant editor with layers support.
I noticed quark but I don't like it too much, I'd prefer to stay on the Radiant side (Gtk radiant, Net radiant, Dark radiant, and so on).
There someone who knows a good editor with this feature?
Because I use Blender (first Maya and first again 3d Studio Max) since 2006 and layers are a basic tool for the map projecting setup IMO and func_group is not an alternative for me

thanks in advance

[Chip]

[goldenboy]

DarkRadiant supports layers very nicely. Unfortunately its wiki page says it can't be used with other games than Doom 3 and The Dark Mod. I haven't tried using it for Quake yet because I have some bug I'm trying to get help with atm.

http://darkradiant.sourceforge.net/index.php

If it can't do Quake maps, then I'll keep using netradiant...

I do not know of other editors that support layers. Older Radiants support groups, ie an entity whose only purpose it is to allow group selection/handling of the brushes in it (using Expand selection to whole entity etc., and then using hide/unhide).

The layers functionality is really very neat. Pity Netradiant doesn't have it. However all Radiants are open source, so someone could port the layers functionality to Netradiant in theory.

Or get Darkradiant working with Quake...

[toneddu2000]

[goldenboy]

This is probably because their knowledge was too limited to maintain GTKRadiant or whatever fork for all games that supports (a lot). They called it Dark Radiant, after the Dark Mod, for a reason :-/

Three possibilities:

1. let's make it work with Quake. I'm in the same boat as you, I also want this. Let's start a thread at their forum and both talk to them (after we try installing the Quake gamepack from GTKRadiant and finding out if it works).

2. Port the layers stuff to Netradiant. I have hacked Radiant before, but depending on how complex the code is it might be over my head.

3. Ask the Netradiant maintainers (div? I forget who it is) to add layers support (and anything else useful) from DarkRadiant.

For Doom 3, which I also map for, Darkradiant seems awesome. If I can get it working.

[toneddu2000]

[goldenboy]

The thing with Blender as a map editor is that it would also need to be able to place entities, triggers, lights etc.

Also, Blender has no grid (edit: I mean no automatic, mandatory grid that conforms to Quake units and can be switched by hotkeys). A grid is hugely helpful when building map geometry. The more complex it gets, the more likely you are to have leaks when you export from Blender to map. There's a reason they used Radiant for idtech4 games and not 100% Max or Maya.

[gnounc]

Keep in mind the .map exporter is not an official plugin, so it wouldnt be the blender devs you'd need to talk to.

On blender placing entities and the like, blender has a python api, i dont think that part of it would be very difficult at all

[toneddu2000]

[goldenboy]

I know that. I am simply concerned about the quality of a map exporter and especially the reliability regarding "no leaks" when the mesh gets very complex. It is simply about the map compiler and the prevention of leaks. Modern games don't have to use TxQBSP.

Doom 3 used boxy corridors, but interspersed with a lot of .lwo mapmodels and patch meshes. I thought that worked quite well. It has no rocky outcrops levels simply because of the theme. ETQW is an idtech4 game that does have lots of outdoor settings and megatextured terrain, and still uses Radiant - as a container, which I think is an adequate role for a level editor, but also for brushwork, indoor areas, and placement of entities. With mapmodels on top. Crysis 2 still uses a (very popular) level editor (with support for brushes).

There might be things a dedicated level editor does better than Blender.

But if Blender can one day be used as a map editor, and produces maps that compile and run properly, then I'll gladly switch to Blender exclusively (I already use it for mapmodels).

[andrewj]

[toneddu2000]

[goldenboy]

Indeed the map and bsp format and the map compiling seem to be a limiting factor here.

A large cube around the map (caulk, practically) would indeed prevent leaks, but also increase the vertex, clipnode etc. count massively and the map would run slower because of that, probably despite any visportal-like methods.

Someone who knows the BSP format and Quake engine very well would need to do this work.

Alternatively, one could just stop using the Quake engine and BSP format, and start using UDK for Quake maps instead. A technical migration to another platform, while keeping the content Quake-themed.

About layers in Netradiant, divverent came up with an idea how to implement it. He put it on the TODO list but he's very busy so it might be a while.