GTKRadiant

[greebo]

While looking for some information about projected lights and the frustum calculation, I found this:

 

- (TODO) Texture sizes sometimes vary wildly. New texture browser option: View -> Fixed Size.

Code parts taken from DarkRadiant. (Shaderman)

 

Seems like the GTKRadiant developers (or at least Shaderman) are well aware of our fork.

[OrbWeaver]

Yes, I saw that a while ago when it came out as part of a svn-commit email to the mailing list.

 

I actually made Shaderman aware of our Model Selector as well, when it came up in a user request. I think they might have some difficulty integrating it though with all of the application-wide changes we have made.

[greebo]

Yes, that's probably the main problem.

 

I'm curious how long it will take the new GTKRadiant developers till they dare to do some serious restructuring to their codebase.

[OrbWeaver]

I think it is inevitable that there will be a fork: DarkRadiant for Doom 3 and its brethren (Q4, Prey etc) and GtkRadiant for the pre-Doom 3 crowd (Quake 3, ET, HL etc). We already have much better support for Doom 3 than vanilla GtkRadiant and once we achieve feature parity with DoomEdit, we will have de facto the best Doom 3 editor available (which is why I am keen to have a particle editor and dynamic shadows, although these are not priorities for TDM).

[greebo]

I subscribed to the GtkRadiant developer mailing list last week and now I'm receiving nothing but spam-o-fied bug reports (and the gmx filter sends most of the GtkRadiant mails into the spam folder, although I added the email address to my white list). First I thought there would be some discussion going on, but it really gets tiresome to sort out all of the useless "car insurance" bug reports...

[OrbWeaver]

Yes, there is very little discussion on that list. It is useful if you want notifications of SVN commits, but the bugreports seem to be a combination of spam and stupid "hay guys gtkradiant dosn't wrko on my computar!!!111" submissions from John Q Public.

[greebo]

Either they get that sorted out soon or the list will get abandoned very soon (at least by me).

[OrbWeaver]

Yeah, I've been meaning to unsubscribe myself but haven't got round to it yet. It was useful during the early development when backporting bugfixes from the mainline was important, but now we are so far ahead of GtkRadiant that merging their bugfixes would be more effort than just fixing them.

[greebo]

Considering that they are still messing around with Half-Life 1 support, it's really no wonder anymore, why they are progressing so slowly. Unsubscribing now...

[OrbWeaver]

Well there is certainly a place for Half-life 1 editors, however writing a single application to support everything requires very well-designed abstraction s, which GtkRadiant simply doesn't have.

 

If they want to support this many games they should start pushing functionality into plugins which implement well-designed interfaces, with different plugins for each game (eclassmgr_hl1, eclassmgr_doom3, eclassmgr_prey) etc. Then the build script should be able to select which plugins to build depending on the game type, allowing them to easily build different versions of the application for different games.

 

The chances of convincing anybody that this is a better design than having hundreds of hardcoded if-statements to select the gametype, is rather remote though.

[greebo]

I scrolled a bit through the GtkRadiant CHANGES file yesterday and for me it provided some new insight into the history.

 

Most of the scenegraph has obviously been written in october 2002 by SPoG (I guess dynamic_cast has already been available at that time ), who has been the most active author for more than 5 years.

 

Is SPoG employed by iD software or is/was he a volunteer like namespace and us? I wonder why he stopped comitting in August 2006?

[sparhawk]

The chances of convincing anybody that this is a better design than having hundreds of hardcoded if-statements to select the gametype, is rather remote though.

 

I wonder why. "IF" is so sexy.

[OrbWeaver]

Is SPoG employed by iD software or is/was he a volunteer like namespace and us? I wonder why he stopped comitting in August 2006?

 

I'm not sure whether he actually worked for ID, but he was certainly in the game industry and had an official address at some publisher or other (possibly EA, I can't remember which). I suspect he was an ex-ID developer who still contributed in his freetime.

 

I guess it was good of him to give up so much time, but his code was pretty poor in many respects. I suspect the majority of the complex templated rubbish was due to him.

[greebo]

Yup. He certainly knew what he was doing though, he (among almost all other things) wrote the experimental support for projected lights, from where I could start off. The templated stuff is of course a nightmare to work with (at least for me).

 

I still have a lot to learn in terms of rendering and elegant matrix transformations, so he sure saved us a lot of time. Too bad his code is completely undocumented - the classic symptom of one-man-programming, as I first suspected.

[namespace]

SpoG was a mapper who started to become popular back in the Q1 (or 2?) days.

He wrote many howtos about q3map2 and other id mapping related things and

picked up GtkR development at the time of GtkR 1.4. Later he got

his own branch because his "interesting" design decisions were a threat to 1.4.

As the 1.4 crew left the project, the spog-branch became the 1.5 branch.

 

The code for projected lights is not from SpoG. Nobody (Spog, Tr3B, me) was able to figure out how ID calculated these matrices, many implementations worked most of time

but failed in some special cases. That code-snippet was given from ID.

 

The renderer isn't from Spog either. It was backported from Tr3Bs x-real engine.

 

I don't want to smallen Spogs work, its still alot of stuff and very complicated too,

but don't give him credits for too much.

 

Concerning the projected light code:

I have no idea how it works, I know projection-transforms very well, but this code is

just insane. My engine just recalculates the projection from the 3 given vectors.

Thats pretty easy to do and looks intuitive enough to me. Yes it may not cover

every possible weird lighing setup you can create with doom3, but I don't consider

this to be a problem.

[greebo]

Ah, ok, I was referring to this entry in the changelog (10/01/2006):

10/01/2006
SPoG
- Added experimental support for doom3/quake4 projected lights.

 

I bit into that piece of frustum calculation code a few months ago (when I worked on the draggable projected light vertices) and failed to wrap my head around it. It's probably very condensed and optimised and without documentation I hardly stand a chance of understanding what is going on here. In the end I decided to use just the result of this code and intersect the resulting planes to calculate the corner points.

 

The lighting mode rendering of projected lights doesn't really work currently, so anything will be an improvement here.

[namespace]

The lighting mode rendering of projected lights doesn't really work currently, so anything will be an improvement here.

Huh, why that? It works in 1.5.

[greebo]

Last time I checked it was incorrectly rendered (only a small circle was projected). Perhaps I used the wrong light shader? I'll check again right now.

[greebo]

No, doesn't work like in DoomEdit. Maybe I even broke it myself when changing the projected light code. I will have to check out the GtkRadiant code it seems.

[greebo]

I just tried out the GtkRadiant behaviour and it definitely works better than DarkRadiant here. If you didn't change anything in the projected lights renderer, I must have broken it somehow.

 

I also found an interesting feature:

 

The light seems to be reflected upwards as well when the light volume is intersecting with a wall on the side. Maybe this is persistent in DoomEdit as well, I haven't checked, but it seems a bit weird.

[namespace]

The light seems to be reflected upwards as well when the light volume is intersecting with a wall on the side. Maybe this is persistent in DoomEdit as well, I haven't checked, but it seems a bit weird.

Well mathematically, the backprojection is correct. The most common way to get rid

of it is to use a texture to mask it out, doom3 combines this with its falloff texture.

If you see the backprojection your falloff texture is completly white

or painted wrong.

 

The frustum looks distorted though.

[greebo]

The distortion was of course done on purpose to test the projection rendering (I dragged the vertices in DarkRadiant and saved the map). The falloff texture is taken from vanilla Doom3 - I don't know what should be wrong here though. I got this with three different falloff textures.

[namespace]

I dragged the vertices in DarkRadiant and saved the map

You can edit the vertices of the lightfrustum? Did you guys add that in DarkRd?

 

I made a little test myself and was surprised, I get backprojection in GtkR too.

I think the only reason I didn't recognise it earlier is that Radiant culls Brushes

that are behind the frustum. I never placed a light that close to a wall that this

effekt would show

 

Anyway, that shouldn't be much of a problem.

Try painting the left or right half of a falloff map black, it should mask out the front/backprojection. Irrc the doom3 falloff starts in the middle of the falloff-texture, so

the center of the texture is the lightvalue for zero distance, left should be negative distance, right positive.

 

I changed that for my engine slightly:

Zero distance is the left edge, max distance the right. That way I can use the full colorprecision when using a 256 pixel falloff-map.

The fallofftextures have CLAMP_TO_BORDER enabled which adds a "virtual" border

to the texture. This little trick kills backprojections since everything with a

s-texcoord < 0.0 ends up on the black border.

[greebo]

You can edit the vertices of the lightfrustum? Did you guys add that in DarkRd?

Yes, I did that back in December, if I recall correctly. I tried to mimick DoomEdit's behaviour, which was the main goal. I implemented it such that you have to switch into Vertex Editing mode to manipulate the vectors. (This whole stuff cost me quite some time.) OrbWeaver also added a LightInspector to conveniently edit the light's properties and convert them into projected lights.

 

You can achieve pretty weird shapes using the light_target, light_up and light_right as well as light_start and light_end.

[namespace]

1.5 is out btw.

 

Released it two days ago, no special changes compared to the earlier nightly builds.

Feedback has been very rare and cautiously optimistic so far.

Not that I really care, I feel great that its over.