DR and its shifting planes

[Obsttorte 1442]

If you only apply the translation any normalization of the normal vector is unnecessary as it won't change anyways.

You're obviously more familiar with the maths than I am, so if you can suggest an improved implementation that gives the correct result with less error we can certainly try using it instead of the old code.

Well, I study maths.

For the implementation something like

Plane3 Matrix4::transform(Plane3 plane) {
Plane3 transformed;
transformed.normal().x() = plane.normal().x();
transformed.normal().y() = plane.normal().y();
transformed.normal().z() = plane.normal().z();
transformed.dist() = plane.dist() - ( m[12]*transformed.normal().x() + m[13]*transformed.normal().y() + m[14]*transformed.normal().z() );
return transformed;
}

This code is correct if the func_static only gets translated.

Edited December 20, 2012 by Obsttorte

[OrbWeaver 527]

What code is executed when we hit the Save button?

 

I haven't analysed the call sequence up to the level of actual UI operations, but the high-level class for writing the map seems to be MapExporter (radiant/map/algorithm/MapExporter.cpp). Its prepareScene() and finishScene() methods are what calls the code to add and subtract the origins — if you put a breakpoint here you should get a stack trace all the way up to the UI. I believe the same exporter class is used in several places to implement Save, Save As, Export Selected etc.

[Obsttorte 1442]

If you want to add a new function that does the trick you don't need this matrix stuff there. It should be enough to pass the translation vector (that is the func_static's origin) to it as an extra argument.

[grayman 2861]

I have to complete my work on another problem, then I'll be away for a week, during which I can read/answer email, but nothing more.

 

After I get back, if this problem is still unsolved, I'll examine the math and see if there's anything I can contribute.

 

Good luck and thanks for working on this.

[Bikerdude 3738]

+1 on what Gman said, I too appreciate this being looked at.

[OrbWeaver 527]

I implemented the translation-only code, which stopped changes to the normal vector but there were still progressive errors in the distance value. Switching to the maths provided by Obsttorte seems to fix this problem, presumably because it is not using unsafe tiny values as intermediates in the calculation.

 

The current behaviour with brushTest1.map is that there is a change between the original map and the first saved version, but multiple load and save cycles after that do not result in progressive changes. Further testing will be required to determine if this is sufficient.

[Obsttorte 1442]

Yippie \o/

[grayman 2861]

Woo-hoo!

 

All mappers will join together on the town commons, raise a statue in your likeness, sing and dance, and raise a glass in your name!

[Tels 268]

And buy Obstorte a beer

[Obsttorte 1442]

I prefer whisky

[Sotha 1905]

Fantastic! Getting this fixed is the best christmas present any mapper could ever wish for!

[demagogue 1173]

Definitely. It was fun to watch you guys crack this nut.

Cheers all around and especially Obsttorte the taffer of the hour & Orbweaver.

Think I may celebrate with some complex func_statics.

[i30817 24]

Isn't it strange that i's moving on save?

[Obsttorte 1442]

This is a problem caused by the conversion.

 

EDIT: The right formula was posted by Tels first. I only explained why the original code wasn'T so good.

Edited December 22, 2012 by Obsttorte

[nbohr1more 2008]

So... will this get rolled-out as as DR 1.7.3 ? or another 1.8 alpha build?

 

Also, would reverting Func_statics to World_Spawn on map load and only making items func_static

before the final save act as a workaround?

 

I am a little concerned about how much challenge this problem will pose to the contest participants.

 

At least they can use DR 1.5.1 though it is much slower...

[grayman 2861]

can't change func_statics to worldspawn automatically because many of them have entity spawnargs that would get lost in the process

[Sotha 1905]

.Ase exporting as a model is a suitable workaround at the moment.

[Obsttorte 1442]

Further testing will be required to determine if this is sufficient.

Just asking: Has this been taking place? Is the problem solved?

Edited December 25, 2012 by Obsttorte

[grayman 2861]

Back from va-ca.

 

Status?

[OrbWeaver 527]

Status?

 

This is the current status (in Git):

 

The current behaviour with brushTest1.map is that there is a change between the original map and the first saved version, but multiple load and save cycles after that do not result in progressive changes.

 

I assume you will want to do your own testing based on the problem as you have experienced it. If this seems to be OK, then we should make a beta build for mappers to test in the wild and ensure that the fix really is complete.

[grayman 2861]

Thanks.

 

I'll pull the latest from the repository and build something to test with.

 

l8r

[grayman 2861]

I can't figure out how to update my copy of the Git repository so it's the latest. I don't see any "update" request, which is what I would use in SVN.

 

??

[grayman 2861]

On second thought, it would probably be best if you make a beta version available so folks other than me can test simultaneously. Different people using it different ways on different func_statics might observe different things. And I'm not doing much mapping atm anyway, because I'm trying to wrap up the fix to a TDM bug.

 

Thanks.

[OrbWeaver 527]

I can't figure out how to update my copy of the Git repository so it's the latest. I don't see any "update" request, which is what I would use in SVN.

 

The corresponding function in Git is "git pull" from the command line or an equivalently-named option in the GUI.

 

On second thought, it would probably be best if you make a beta version available so folks other than me can test simultaneously.

 

That makes sense. My Windows build environment should hopefully still be functional so I will make a beta build and upload it to the DR website for testing.

[demagogue 1173]

Interestingly there was an article on the philosophy of GitHub & why things are "pulled" in the NYTimes today.