DarkRadiant vs DoomRadiant

[motorsep]

Not a flame war topic

 

Basically, DoomRadiant doesn't have issue with snapping brush planes to integers (NetRadiant has an option to enforce that and I am failing to understand what happened to this option in DR, since both Net and DR were forked from GTKR 1.5). No matter how many times maps are worked on and saved/loaded, there are no gaps forming between brushes.

 

Therefore, I wonder what advantages DarkRad has over DoomRad, pertaining to Doom 3 mapping ?

 

I know that layers is one big thing. A few standard tools that are quite useful that DoomRad doesn't have (one is to create hollow room without brushes intersecting). Objects manipulation widget is awesome too.

 

What else am I missing?

[Sotha]

Readable editor, particle editor, S&R editor...

[AluminumHaste]

There's TONS of stuff that is just Darkmod related. Just go through the code commit comments on SVN for DarkRadiant and see for yourself. Going back to QERadiant/DoomRadiant would make life a lot harder for anyone making maps for DarkMod.

[motorsep]

Yeah, I bet there are a lot of features related to DarkMod specifically. But I pointed out in my initial post about _Doom 3 mapping_.

 

That bug with precision loss in time and thus corrupted maps is a big spoilage for DarkRadiant

 

Other than that fixed, along with Animation viewer, DarkRadiant would be the most robust level editor for idTech 4+ engines.

[Springheel]

The "precision loss" issue you refer to was fixed already, wasn't it?

[New Horizon]

I thought it was too.

[grayman]

Floating point roundoff errors still exist, and can cause planes to shift over a LOOOONG period of time.

 

The bigger problem was in how objects were losing precision as they were being written and read, and solving that problem did away with the most blatant plane shifting.

[motorsep]

Floating point roundoff errors still exist, and can cause planes to shift over a LOOOONG period of time.

 

Why not to use integers for coordinates? A button in the GUI that turns on integers instead of floats for planes/edges/verts when translating / resizing brushes.

[grayman]

Why not to use integers for coordinates? A button in the GUI that turns on integers instead of floats for planes/edges/verts when translating / resizing brushes.

 

Major change, no one to do it.

[motorsep]

Major change, no one to do it.

 

If you can point me in the right direction, we might be able to fix that.

[grayman]

Send a PM to Orbweaver, the most recent person to work on DR.

[Sotha]

Yes, the shifting plane issue is still there. If you have func-static (with non-90-degree planes) and drag it around, it will be corrupted. Worldspawn object were unaffected, IIRC.

 

Planes corrupting upon save/load was fixed.

[motorsep]

Why would you make func_static out of brushes?

 

And what are worldspawn objects? Everything exists inside worldspawn anyway

[Sotha]

Many reasons. If it is a func_static, you can controls shadows, solidity and do other things. Also fs is optimizing tool because it prevents worldspawn brushes generating more unneeded tris.

 

Often, if you keep all objects as ws, you will run into variety of problems.

 

Generally, only the sealing geometry should be ws. All the details should be fs.

[AluminumHaste]

Also adding many brushes to worldspawn cause them all be drawn with one call as opposed to a draw call for each one. Or something like that, it makes the scene render faster.