Manipulation Of Func_statics

[SneaksieDave]

I'll give it the QA-go if you wish. I held off on getting the drop from yesterday because I was sure what 'map changes' meant (I thought maybe as soon as you make a change it crashes), but if there's a new one up I'll try it out.

[greebo]

I uploaded a build half an hour ago, so feel free to test it out. Expect more to come this evening.

[SneaksieDave]

Observations so far:

 

-not seeing a crash on map loads

 

-rotation or shifting of texture is now prevented on rotation or translation of brush entities with texture lock, however,

 

-disabling texture lock doesn't allow brush rotation to have any effect on the texture either (translation seems to work correctly)

 

-rotation of a multibrush entity makes the origin spiral out into space; I made a test func_door out of three blocks in a triangle shape, and when I tried horizontal rotation of the group, the origin went off flying

 

-brush entities made prior to this build seem to be broken somewhat: the origin stays where it was defined previously, but the brush(es) themselves are now centered around worldspawn, 0 0 0. Any idea why, or if there's an easy fix? Did something about the brush definition change? If there's a workaround (or if it's just a simple bug) I'll wait and see before rebuilding all the func_* brushes of my map (it's not that many).

 

I made a simple test to check; created a single brush func_door of exact size and origin in 0.8.1. I then recreated the same brush in latest SVN. Comparing the two, there are definite differences:

 

Original 0.8.1 func_door definition:

brushDef3
{
( 0 0 1 -64 ) ( ( 0.015625 0 2 ) ( 0 0.015625 2 ) ) "_default" 0 0 0
( 0 1 0 -64 ) ( ( 0.015625 0 62 ) ( 0 0.015625 0 ) ) "_default" 0 0 0
( 1 0 0 -64 ) ( ( 0.015625 0 2 ) ( 0 0.015625 0 ) ) "_default" 0 0 0
( 0 0 -1 -64 ) ( ( 0.015625 0 2 ) ( 0 0.015625 62 ) ) "_default" 0 0 0
( 0 -1 0 -64 ) ( ( 0.015625 0 2 ) ( 0 0.015625 0 ) ) "_default" 0 0 0
( -1 0 0 -64 ) ( ( 0.015625 0 62 ) ( 0 0.015625 0 ) ) "_default" 0 0 0
}

Latest SVN, same exact position:

brushDef3
{
( 0 0 1 -64 ) ( ( 0.015625 0 0 ) ( 0 0.015625 0 ) ) "_default" 0 0 0
( 0 1 0 -192 ) ( ( 0.015625 0 0 ) ( 0 0.015625 0 ) ) "_default" 0 0 0
( 1 0 0 -192 ) ( ( 0.015625 0 0 ) ( 0 0.015625 0 ) ) "_default" 0 0 0
( 0 0 -1 -64 ) ( ( 0.015625 0 0 ) ( 0 0.015625 0 ) ) "_default" 0 0 0
( 0 -1 0 64 ) ( ( 0.015625 0 0 ) ( 0 0.015625 0 ) ) "_default" 0 0 0
( -1 0 0 64 ) ( ( 0.015625 0 0 ) ( 0 0.015625 0 ) ) "_default" 0 0 0
}

[greebo]

-not seeing a crash on map loads

That's good.

 

-disabling texture lock doesn't allow brush rotation to have any effect on the texture either (translation seems to work correctly)

I just rotated a multi-brush func_static without TextureLock and the texture changed, so I can't reproduce this.

 

-rotation of a multibrush entity makes the origin spiral out into space; I made a test func_door out of three blocks in a triangle shape, and when I tried horizontal rotation of the group, the origin went off flying

Confirmed, I'll try to fix that.

 

-brush entities made prior to this build seem to be broken somewhat: the origin stays where it was defined previously, but the brush(es) themselves are now centered around worldspawn, 0 0 0. Any idea why, or if there's an easy fix? Did something about the brush definition change? If there's a workaround (or if it's just a simple bug) I'll wait and see before rebuilding all the func_* brushes of my map (it's not that many).

 

I made a simple test to check; created a single brush func_door of exact size and origin in 0.8.1. I then recreated the same brush in latest SVN. Comparing the two, there are definite differences:

This is not good, I will check that.

[greebo]

Ok, I just discovered that patches that are part of func_statics are NOT measured relatively to the func_static origin:

 

Compare the two patches of worldspawn and func_static (created by DoomEdit):

Version 2
// entity 0
{
"classname" "worldspawn"
// primitive 0
{
brushDef3
{
 ( 0 0 -1 0 ) ( ( 0.03125 0 -1 ) ( 0 0.03125 2 ) ) "textures/common/trigentityname" 0 0 0
 ( 0 0 1 -8 ) ( ( 0.03125 0 -1 ) ( 0 0.03125 -2 ) ) "textures/common/trigentityname" 0 0 0
 ( 0 -1 0 104 ) ( ( 0.03125 0 -2 ) ( 0 0.03125 0 ) ) "textures/common/trigentityname" 0 0 0
 ( 1 0 0 -504 ) ( ( 0.03125 0 -1 ) ( 0 0.03125 0 ) ) "textures/common/trigentityname" 0 0 0
 ( 0 1 0 -288 ) ( ( 0.03125 0 2 ) ( 0 0.03125 0 ) ) "textures/common/trigentityname" 0 0 0
 ( -1 0 0 320 ) ( ( 0.03125 0 1 ) ( 0 0.03125 0 ) ) "textures/common/trigentityname" 0 0 0
}
}
// primitive 1
{
brushDef3
{
 ( 0 0 -1 0 ) ( ( 0.125 0 0 ) ( 0 0.125 0 ) ) "textures/common/trigtimer" 0 0 0
 ( 0 0 1 -8 ) ( ( 0.125 0 0 ) ( 0 0.125 0 ) ) "textures/common/trigtimer" 0 0 0
 ( 0 -1 0 -48 ) ( ( 0.125 0 0 ) ( 0 0.125 0 ) ) "textures/common/trigtimer" 0 0 0
 ( 1 0 0 -528 ) ( ( 0.125 0 0 ) ( 0 0.125 0 ) ) "textures/common/trigtimer" 0 0 0
 ( 0 1 0 -152 ) ( ( 0.125 0 0 ) ( 0 0.125 0 ) ) "textures/common/trigtimer" 0 0 0
 ( -1 0 0 328 ) ( ( 0.125 0 0 ) ( 0 0.125 0 ) ) "textures/common/trigtimer" 0 0 0
}
}
// primitive 2
{
patchDef2
{
 "textures/common/trigentityname"
 ( 3 3 0 0 0 )
 (
  (  ( 168 -24 232 0 0 ) ( 112 108 0 0 12.5 ) ( 192 304 232 0 25 ) )
  (  ( 212 8 0 12.5 0 ) ( 212 108 0 12.5 12.5 ) ( 212 208 0 12.5 25 ) )
  (  ( 312 8 0 25 0 ) ( 312 108 0 25 12.5 ) ( 312 208 0 25 25 ) )
 )
}
}
}
// entity 1
{
"classname" "func_static"
"name" "func_static_1"
"model" "func_static_1"
"origin" "320 128 112"
// primitive 0
{
patchDef2
{
 "textures/common/trigentityname"
 ( 3 3 0 0 0 )
 (
  (  ( 168 -24 232 0 0 ) ( 112 108 0 0 12.5 ) ( 192 304 232 0 25 ) )
  (  ( 212 8 0 12.5 0 ) ( 212 108 0 12.5 12.5 ) ( 212 208 0 12.5 25 ) )
  (  ( 312 8 0 25 0 ) ( 312 108 0 25 12.5 ) ( 312 208 0 25 25 ) )
 )
}
}
// primitive 1
{
brushDef3
{
 ( 0 0 -1 -112 ) ( ( 0.125 0 0 ) ( 0 0.125 0 ) ) "textures/common/trigtimer" 0 0 0
 ( 0 0 1 104 ) ( ( 0.125 0 0 ) ( 0 0.125 0 ) ) "textures/common/trigtimer" 0 0 0
 ( 0 -1 0 -176 ) ( ( 0.125 0 -0 ) ( 0 0.125 0 ) ) "textures/common/trigtimer" 0 0 0
 ( 1 0 0 -208 ) ( ( 0.125 0 0 ) ( 0 0.125 0 ) ) "textures/common/trigtimer" 0 0 0
 ( 0 1 0 -24 ) ( ( 0.125 0 -0 ) ( 0 0.125 0 ) ) "textures/common/trigtimer" 0 0 0
 ( -1 0 0 8 ) ( ( 0.125 0 0 ) ( 0 0.125 0 ) ) "textures/common/trigtimer" 0 0 0
}
}
// primitive 2
{
brushDef3
{
 ( 0 0 -1 -112 ) ( ( 0.03125 0 -1 ) ( 0 0.03125 2 ) ) "textures/common/trigentityname" 0 0 0
 ( 0 0 1 104 ) ( ( 0.03125 0 -1 ) ( 0 0.03125 -2 ) ) "textures/common/trigentityname" 0 0 0
 ( 0 -1 0 -24 ) ( ( 0.03125 0 -2 ) ( 0 0.03125 0 ) ) "textures/common/trigentityname" 0 0 0
 ( 1 0 0 -184 ) ( ( 0.03125 0 -1 ) ( 0 0.03125 0 ) ) "textures/common/trigentityname" 0 0 0
 ( 0 1 0 -160 ) ( ( 0.03125 -0 2 ) ( 0 0.03125 0 ) ) "textures/common/trigentityname" 0 0 0
 ( -1 0 0 0 ) ( ( 0.03125 0 1 ) ( 0 0.03125 0 ) ) "textures/common/trigentityname" 0 0 0
}
}
}

[SneaksieDave]

I just rotated a multi-brush func_static without TextureLock and the texture changed, so I can't reproduce this.

Huh, you're right, I just tried again and it was fine. Maybe it was one of my previously built doors, which seem to have the other problem as well, causing it.

This is not good, I will check that.

Cool, glad I wasn't losing my mind on that.

 

Edit: just saw your post. Is that about the shift back to origin? The items I meant don't contain patches, just for the record.

[greebo]

Yes, this problem is probably related to it. Additionally it seems to break the portability to DoomEdit, which is why I raised the severity of this bug to major.

 

I can't understand why patches are handled inconsistently by Doom3, but after all it's my fault not having checked that before I implemented the current solution. Good thing is , that the solution doesn't work either, that's why you don't see the patches jumping, but the brushes.

 

Oh dear, I hope I can fix this, I had already thought that this problem was solved...

[greebo]

Next surprise: The func_static origin gets recalculated by DoomEdit everytime you open the map. This means that you can change the origin by hand (just type in any value in the Entity Inspector), save - and next time you open the map, the origin is where it was before.

 

Do we have a DoomEdit bug here or is this intended behaviour? How is a mapper supposed to set the origin by hand if it gets reset every time you open the map?

[SneaksieDave]

No, you can definitely have repositioned origins in DoomEd (if that was the question), and they're saved. It's the way to set non-standard hinges for doors, or nonstandard rotation axis in general.

[greebo]

We are both referring to the origin key, represented by the small red dot, aren't we?

 

This is what I did in DoomEdit:

 

I created two brushes and made them a func_static (the origin is at ):

 

I repositioned the origin by typing in the values

 

Then, saved the map (test2.map), the origin is saved correctly (I checked the .map file using a text editor). Click File>Open>test2.map to re-load the map:

 

Hit save again, and the origin is back at . Obviously the origin is recalculated at the centroid of the child primitives, which sucks hard, IMO.

 

edit: It seems that the func_door origin is not being recalculated, I just checked.

[greebo]

Ok, another try: I think I have fixed the issues now.

 

My approach is as follows:

- During map load/save, the origin is added/substracted to all the child primitives of the func_static, func_doors and such.

- As a consequence, all the operations on the child primitives work as they would for worldspawn primitives, no hacks, no IFs.

- The origin is left untouched by rotation operations, preventing it from sailing on this large orbit around the func_static.

- Translations affect the origin as usual

- Child primitives can still be traversed by using the TAB/Shift-TAB keys.

- The origin can manually be changed using the Entity Inspector without affecting the children.

 

I tested porting several entites to DoomEdit back and forth, and it seemed to work. So far the geometry as well as the texturing is preserved.

 

After removing most of my debug outputs, I'll upload a new build to the FTP server.

 

edit: new snapshot is on FTP.

[SneaksieDave]

Oh, was the question that DoomEd doesn't handle it or that the previous DR didn't? DoomEd must handle it, because... well, aside from a whole game build up around it , I used it in the rain and snow maps for the hinged windows.

 

So to clarify then, I guess there's no more breakage at all with DR->DoomEd or DoomEd->DR. I wasn't clear on this, it sounded like saving in DR was breaking the map for DoomEd, so I was wary to do any "real" work in DR. Will be checking it out today for sure.

[greebo]

To clarify: DoomEdit does recalculate all the origins of func_statics on map load, but NOT the origins of func_door entities. I haven't checked any other funcs though.

 

DR does no recalculation of origins on map load.

[SneaksieDave]

How does DoomEd know where the origin for a func_door is? The rain map always worked (it would need updating for name changes), and when I reopen a map now which uses a func_door, the origin is still offset.

[greebo]

There seems to be a misunderstanding: Let me repeat: The origin of func_static is recalculated (at the centroid of the child primitives), the origin of func_door stays untouched. This is concerning DoomEdit.

 

func_static != func_door

[SneaksieDave]

I'm fully aware of that. I think we are talking about the same thing but from different perspectives. You're saying 'recalculated' to mean it's back at the center. I was taking 'recalculated' as meaning that an offset is applied after load, so that it is not at the center.

[greebo]

If we're talking about the same things, it's ok.