Entity Creation Issue

[greebo]

I'm experiencing some issues while creating readable entities with DarkRadiant. The problem is: when I create an entity out of my two brushes (the parchment and the entitygui) the "origin" key is not created by DarkRadiant. DoomEdit however does create the key (its value should be at the geometric center of the two brushes).

 

As a result, I'm unable to read the parchment, it never appears on the screen after frobbing (the screen fades out and in very quickly, as it is supposed to do). I suspect that the missing origin value is assumed to be "0 0 0" and the readable appears somewhere out of my field of view. As a consequence the readable_face_tolerance value is kicking me out of reading mode.

 

This problem only seems to occur when creating entities out of brushes, as lights and other entities that can be created without a brush selected (I tested with atdm:loot_vase) get their origin value set correctly.

 

I'm using the latest compile from SVN (but the problem appears in version 0.5.3 as well). Perhaps this is a known issue, but I thought I'd post it here. I can post the differences of the two map files (from DarkRadiant and DoomEdit), if it is helpful.

[OrbWeaver]

It's not a known issue, but certainly a believable one, given that creating funcs from brushes was broken until recently. Hopefully it should not be too difficult to calculate and insert the origin key.

[greebo]

There seems to be another issue connected with the above one. If you create your brush-based entities in DarkRadiant and open up the map in DoomEdit it totally screws up your brush positions. It seems that the missing origin key is added by DoomEdit automatically on saving and the coordinates are not corrected accordingly.

 

This is kind of annoying, as all our func_liquids got scattered all over the map and we had to reposition all of them.

[OrbWeaver]

I have started to investigate this. It seems that the actual "centrepoint" of the entity is placed at world origin when it is created, so adding the "origin" key afterwards causes the entity to undergo an additional translation, which is not what we want.

 

Interestingly, vanilla GtkRadiant does not set this key either. I wonder if standard Doom 3 users ever noticed this problem.

[OrbWeaver]

Played around with this a bit more, in DoomEdit.

 

It seems that when brushes are reparented in DoomEdit (i.e. made into child brushes of a func_static or similar), their coordinates are changed from absolute world coordinates to relative coordinates in "entity space", based on the position of the entity's "origin" key.

 

To solve this, DarkRadiant will need to do two things when reparenting brushes:

 

1. Calculate the "origin" key and set it on the new entity

2. Transform all of the brushes' coordinates to be relative to this new origin. I imagine this is a simple as subtracting the origin vector from each 3D coordinate.

 

Given the relative coordinates, it is probably unimportant where the actual origin is placed, although the centre of the bounding box seems a logical choice (and also the easiest to compute).

 

There is of course scope for a hack here -- just set the origin to "0 0 0", then no relative coordinates are necessary (because the func_static's origin will be the same as the world origin). I imagine this would be confusing to mappers however.

 

EDIT: Actually, is this really that much of a hack? Do mappers actually need an origin key for brush-based entities, or is this just something to keep the game happy?

[Gildoran]

It is neccesary. The origin is what the entity rotates around, for one thing.

[OrbWeaver]

It is neccesary. The origin is what the entity rotates around, for one thing.

 

Not in DarkRadiant it isn't. The centre point for rotation is calculated each time as the centre of the AABB.

[greebo]

There is of course scope for a hack here -- just set the origin to "0 0 0", then no relative coordinates are necessary (because the func_static's origin will be the same as the world origin). I imagine this would be confusing to mappers however.

 

EDIT: Actually, is this really that much of a hack? Do mappers actually need an origin key for brush-based entities, or is this just something to keep the game happy?

The origin should really be in the geometric center of the entity brushes (at least for the readables), as the code for readables relies on this value.

 

If you placed the origin somewhere in the room next door (for instance) and frobbed the readable brushes, the onscreen readable would not show up in the center of your monitor. I can post a screenshot illustrating this if you want, I'm not sure if I'm explaining this clearly enough.

 

This also happens when I move the readable brushes away from where the entity was originally created, as the origin value of the entity is not updated when moving its brushes (at least in DarkRadiant). The onscreen readable would not appear where you expect it to, the center would always be directed towards the entity's origin, not towards the brushes. So, at the moment I create my readable and leave it right where they are. If I need them at a different location, I delete the entity and create a new one.

 

I also tried selecting the entity in the entity list and dragging the brushes around, but that does not work either, as the brushes are highlighted but somehow frozen as long as the entity itself is selected.

[Gildoran]

Not in DarkRadiant it isn't. The centre point for rotation is calculated each time as the centre of the AABB.

I mean the orign is what D3 rotates the entity around. If a script tells an object to start rotating, it rotates around its origin. If you set an angle in the spawnargs, the entity gets rotated by that angle around its origin upon being spawned, and shows up that way in D3ed.

 

If DarkRadiant always has the origin at 0, I imagine things like darkmod doors wouldn't work. This is also why it's important for the user to be able to easily see/edit the origin graphically in addition to typing in numbers: it makes it easier to place the axis of rotation for darkmod doors, or the focus for readables.

[OrbWeaver]

OK, I'll have to add the code to transform the brush coordinates into entity space as well -- it shouldn't be too difficult, although it is obviously more complex than using a hardcoded value.

 

This also happens when I move the readable brushes away from where the entity was originally created, as the origin value of the entity is not updated when moving its brushes (at least in DarkRadiant).

 

Would you prefer the whole entity to be selected and moved as a single unit? This is what DoomEdit does, but I noticed in DarkRadiant the brushes are still selected and moved independently which I find a bit annoying.

[Gildoran]

I usually prefer things to be selected and moved as a unit, but there are times when I wished I could have edited the brushes of an entity without having to convert to worldspawn and back, losing spawnargs along the way. It'd be great if there was an option to turn on the independant brush code.

[greebo]

Would you prefer the whole entity to be selected and moved as a single unit? This is what DoomEdit does, but I noticed in DarkRadiant the brushes are still selected and moved independently which I find a bit annoying.

At least for the readables it would make sense to handle them as a single unit as long as the texturing of the single brushes stays unaffected. I would vote for the DoomEdit solution.

 

I can't say if there is a case where it would be an advantage to move the child brushes of an entity independently as I've not that much experience with the Dark Mod entity types.

[OrbWeaver]

You can edit the invididual brushes in DoomEdit by pressing TAB. I would endeavour to implement a similar function in DR if "unit mode" was used by default.

[Gildoran]

I didn't know that... I'll have to try it out some time. Thanks for mentioning it!

[OrbWeaver]

I have now added code to set the origin key and adjust the brushes' coordinates to take into account the new origin. There will probably be some work left to do, in particular I am not convinced that the dragging behaviour is correct once the entity is created.

[greebo]

Cool, I will compile it right now and test it (after lunch of course ).

[greebo]

It did not work at first, the plane coordinates did not change after the creation of the entity (it got moved after re-opening the map file in DarkRadiant).

 

I could track the problem down and solve it by changing this (in map:cpp:1767)

Brush* brush = Node_getBrush(path.top());
if (brush != 0) {
	// We have a brush, apply the transformation
	brush->transform(_transMat);
}

to

Brush* brush = Node_getBrush(path.top());
if (brush != 0) {
	// We have a brush, apply the transformation
	brush->transform(_transMat);
	brush->freezeTransform();
}

Now the brush coordinates get saved as well and the brushes stay in place. I will do some more testing and report if I find something more.

[OrbWeaver]

Thanks, that is committed now.

 

I thought something was wrong when editing the origin key after creating the entity didn't seem to do anything -- now it moves the brush as expected.

[greebo]

It's now possible to create a working readable in DarkRadiant, everything seems ok! Thanks for adding it!

 

I had another issue while doing a full compile it complained about a missing "entityinspector.h" in groupdialog.cpp:42. After chaning the string to "ui/einspector/entityinspector.h" (i.e. including the relative path) it compiles without errors.

 

Has this something to do with the sconscript or is this include supposed to happen this way (including the path)?

 

Edit: Ok, I had some trouble posting this - at first I had the word "g plus plus" within my text, which the forum didn't like at all...

[OrbWeaver]

I had another issue while doing a full compile it complained about a missing "entityinspector.h" in groupdialog.cpp:42. After chaning the string to "ui/einspector/entityinspector.h" (i.e. including the relative path) it compiles without errors.

 

I suspected this might happen -- I finally removed the old entityinspector.h from the build tree, but scons doesn't notice when you delete a header file so error doesn't happen until you do a full manual build, which I forgot to do before committing. It is fixed now.

[greebo]

Thanks for your fast responses and updates, it's really appreciated. I feel a little strange about bugging you with these issues, I hope I'm not wasting your time here.

[OrbWeaver]

Not at all, I wish more people would do this. You are performing the very useful function of User Acceptance Testing (testing that the product allows the user to accomplish his tasks) in contrast to my Unit Testing (testing that the particular feature works as designed).

[greebo]

Ok, glad to hear that, I hope I can contribute more in the future. Perhaps I will even be able to add some functionality myself when I'm familiar enough with the source code.

 

Another question: is there some sort of todo list for DarkRadiant or a list of accepted feature requests apart from the Wishlist thread? I'm just curious about the progress and what is planned.

[OrbWeaver]

We have a task tracking thread in the Programming forum, the current planned features include - preview in the model selector (currently it is blank), Doom3-style media browser, draggable light centers, automatic monsterclip and noshadow options for creating new models, plus various code-level issues like renderer performance. There will also be a need for more DarkMod specific features like stim and objective editors, but those are not past the "we kind of need this" phase as yet.