What is missing from Rad/GTK/D3Rad/Q4Rad, for you...?

[$NulL]

Better texture alignment tools, ie as close to actual control of vertex texture coordinates as possible.

I just spent the better part of an afternoon getting the textures lined up on a winding road I built with brushes in radiant. As its not possible in radiant. I had to to compile the road, convert it to an ase model. Open it in Max, merge all the road surfaces together, weld a bunch of vertexes, uvUnwrap the texture coords. Export as a new ase model, load back into radiant, and caulk the origianl brushes. Long way round or what?

[axbaby]

lighting is a bitch
easy lighting
highlight an area in the editor by drawing lines outlining the area you want lit.

in Rad a pull down box gives you these options
-auto light area dark
-auto light area morning
-auto light area day
-auto light area outdoors
-auto light full map day
-auto light full map night
then tweak the light entities with colour and junk
impossible ?

[o'dium]

Autolight, in a per pixel lit game editor...?

Yeah ok. I'll add it just left of the "make level" button

[jal_]

I don't think groups are supported for entities

Another thing that would improve radiant greatly. A object browser like the one at quark (or maya, and many others). It could create a different file for the tree or write it directly inside the map file as comments.

Better texture alignment tools, ie as close to actual control of vertex texture coordinates as possible.

+1 And uv mapping for patches

I always hated the way radiants have the selection clicks. Clicking shouldn't create a brush but select whatever you click and deselect whatever you have selected. Something as simple as that would improve radiants inmensely for me. A little better texture placement tools would be nice too, but the most important is the selection clicking to work like any other program in the world

I've always liked the way just clicking on the screen creates a brush. Quick and dirty. It's especially helpful to me if I already have a decent idea of what I'm going for atm. Personal preference which goes back to the customizable bind cfg.

It's not just personal preference, when you're doing a tool for a new game you have to consider the intuitiveness of it for future artists. They will come from using other tools than radiant unless you are doing your game exclusively for the quake comunity.

I work with 3 or 4 modelling/mapping tools at once, and it's a pita when they work basically the same excepting at the point where I focus radiant. I'm not against the brush drag-build thing, but for coherency between applications the just-click should be "select" as at every other application, and the drag-build should be a tool as the clipper is, with its own key combo. Specially because when lacking the most basic select you have to loose time deselecting before selecting, and in most cases that means hitting ESC several times.

[Fjoggs]

1.5 was in the beginning almost completely the same as 3ds max and maya in terms of how to interact with brushes, but was changed back to how it was done in earlier releases because people hated it.

[Scourge]

It's not just personal preference, when you're doing a tool for a new game you have to consider the intuitiveness of it for future artists. They will come from using other tools than radiant unless you are doing your game exclusively for the quake comunity.

I work with 3 or 4 modelling/mapping tools at once, and it's a pita when they work basically the same excepting at the point where I focus radiant. I'm not against the brush drag-build thing, but for coherency between applications the just-click should be "select" as at every other application, and the drag-build should be a tool as the clipper is, with its own key combo. Specially because when lacking the most basic select you have to loose time deselecting before selecting, and in most cases that means hitting ESC several times.

So, yeah, personal preference. Make it selectable to be more like radiant, or more like maya, etc., or completely your own style.

[o'dium]

Well, I'm not sure how easy that will be to add because it will require testing for all of them. I can say however that ODRad no longer saves to the registry, and instead saves ALL settings to a config file, INCLUDING key binds, so that will really help quite a few of you out.

[obsidian]

Autolight, in a per pixel lit game editor...? Yeah ok. I'll add it just left of the "make level" button

I think he means something like click once to place a light origin, and then drag to set the radius. This would be nice, especially with lightmapped maps so it will automatically set intensity values.

I can say however that ODRad no longer saves to the registry...

I don't think Radiant ever did save settings to the registry being a Gtk cross-platform API (Linux and Mac have no registry). Settings were saved in one of the .cfg or .rc files, can't remember which.

[o'dium]

Well, RAD does, its in the source.

Anyway, the light scaling is in because its in Q4Rad. You make a light, you can scale it like a brush and see it update in realtime.

[g0th-]

They're not, seeing how groups are considered entites in the editor.

You got me there

[Kat]

...It's not just personal preference, when you're doing a tool for a new game you have to consider the intuitiveness of it for future artists. They will come from using other tools than radiant unless you are doing your game exclusively for the quake comunity.

I work with 3 or 4 modelling/mapping tools at once, and it's a pita when they work basically the same excepting at the point where I focus radiant. I'm not against the brush drag-build thing, but for coherency between applications the just-click should be "select" as at every other application, and the drag-build should be a tool as the clipper is, with its own key combo. Specially because when lacking the most basic select you have to loose time deselecting before selecting, and in most cases that means hitting ESC several times.

You've got it wrong.

All 3D apps should work like GTK/Radiant. 'Nuff said.

[wattro]

all good editors need ways to apply properties to instances, whether its textures, brushes, entities, whatevs

i would love to have a scene layout like many modelling programs do, so i can easily view the tree, hide/show/select nodes, etc... that would probably fuck the .map file and might be the same thing someone else suggested already, but so what... the .map file needs a serious upgrade and what better time to do it than now

[o'dium]

In what sense wattro? Rad has hide/show function, and I'm getting serk to hide anything flagged with decal in the material so that mapping is easier. Anybody who has mapped for anything later than Q3 knows that maps get crazy with decals all over the shop lol.

But you can already skip pretty much anything you want, patches, brushes, flares, clip, caulk, hint, models, terrain etc etc...

[jal_]

odium, he means like quark's object browser, maya's outliner, etc. I suggested that too in a post that was lost at one of those quake3world fall times. I think the tree information could be written into the actual map file as comments. That also allows to create groups for editing that are not func_group entities.

Bottom left pannel:

[o'dium]

Thats already done, lol. Its there already in Rad you just have to mess with the ini file

EDIT: oops, no its not. But yeah thats in Q4Rad and I wouldn't not add it tbh, its easier that way.

[obsidian]

I wouldn't not add it tbh, its easier that way.

Huh?

[axbaby]

what i meant was a better way of setting the ambient light just to get you started.

[o'dium]

I see... Well, i dunno, whats so hard about adding a light

Oh baby baby!

[$NulL]

There's an entity tree view already in radaint, by pressing 'L'. I dont know of anyone that actually uses it though. If things could be grouped then, I think it would be more useful.

I think the tree information could be written into the actual map file as comments.

Ya, something akin to:

Code: Select all

// brush 0
// group worldspawn>BuildingA>Room1
{
( 648 192 -8 ) ( -240 192 -8 ) ( -240 -64 -8 ) common/caulk 0 0 0 0.500000 0.500000 0 0 0
...