DR and its shifting planes

[Obsttorte 1440]

according to what I've read in this thread I'd like to make two suggestions that may help in this issue:

 

the first one was already metioned by someone else before: DR should only save brushes/patches ... that have been changed

so it converts everything into the format it needs on load but also keeps a copy of the normal format used in the map files so it can than merge both things together upon saving

 

a second idea is to let DR save a second file in which it stores on which minimum grid size a brush or patch was modified

if it than transformes the planes into normal format it can than round the values to an appropiate digit

 

For example, here's one plane definition from the brush that's showing the most caulk in the picture above:

 

( 1 0 0 -91.93686676025391 ) // the normal is in the +X direction and the origin is 91.93686676025391 units behind the plane's face

 

If I correct the brush and put it back where I first drew it many moons ago, that plane definition reverts back to what it was originally:

 

( 1 0 0 -92 )

this is a good example for what I mean. if the brush this plane belongs to was modified on a grid-size not smaller than one, the origin cannot have digits behind the dot, so the code would know it has to round it

 

on a min. grid-size of 8 the code would than for example round it to something like 8*X

 

of course this only works with the origin in this way, but IMO also the normal entrees can only take specific values depending on the minimum grid-size used

[grayman 2781]

The problem is, if you are still using "plane equation => 3 points => plane equation", you will still have floating point errors and the problem will still occur. You have to think of the common situation of "on morning, load map, on evening save" and multiply this a few hundred times.

 

Any floating point errors will be deltas off the 3 points, which are far less likely to "travel" than the normal/distance plane equation.

 

Having the map stored in an interim format and then have to "export" it for the game would just make it more cumbersome for the mapper, and still not really solve the problem.

 

1 - While I agree it's an extra step for a mapper, it's a step that only needs to be taken at build time, and which does not affect the map information that the mapper will continue on with. It's just a snapshot, left behind at the side of the road as the mapper continues on with the interim copies of the map. And certainly the amount of time the mapper wastes now and then on this extra step no way compares with the amount of time the mapper will spend correcting all the angled brushes that would otherwise be broken as time goes by.

 

2 - If the formatting change solves the problem, then the problem does not reappear because of having to occasionally build and test the map. See #1.

[grayman 2781]

@Obsttorte:

 

While your suggestions are sound, they're beyond my capabilities with DR. I've never worked with its source before.

 

You should file your suggestions in bugtracker so that the "real keepers of DR" can address them.

 

Thanks.

[Obsttorte 1440]

I'll try that.

 

Btw.: how did you change the output format without touching the source.

 

I like the idea with the interim version. But for this to work in a not annoying way for the mapper (meaning he don't take notice) would mean to change the dmap process, so that it converts the interim version to the final version before dmapping or to change DR in a way that it always saves both versions but only loads from interim.

 

Some Coders are needed.

[grayman 2781]

Btw.: how did you change the output format without touching the source.

 

I didn't. I changed the source. Some of the code was already in place, but unused. I just needed to add what was missing.

 

... change the dmap process ...

 

I have no plans to change dmap or anything else in the engine or tools that rely on the idTech4 format.

 

I think of it this way: I'm working in Photoshop, keeping my work in *.psd files. When it's time for me to publish the finished product, I save it in *.jpg or *.tga or whatever format and publish that. I'm keeping my interim work in a format that Photoshop understands (*.psd), and sending my work in a different format to others.

 

I see no reason why DR can't be used in the same way.

[Obsttorte 1440]

well, that would be the second suggestion than

 

anyways, someone has to implement this

[Obsttorte 1440]

You should file your suggestions in bugtracker so that the "real keepers of DR" can address them.

did that, but "Obsttorte" already existed (maybe my mistake)

so the statement is from "Obstler"

[grayman 2781]

A data shifting problem was introduced into DR sometime in the past 2 years that's independent of how plane info is stored in the map file. I checked versions of a map I was working on back in Apr/May of 2010, and the data between versions more than 20 write/reads apart was identical down to the 15th decimal place.

 

If you save a map with today's DR, then compare it with the previous version of that map, you're guaranteed to see data shifting. In most cases the amount of shift isn't going to affect what a mapper or player sees, but certain fragile objects like angled planes are going to visibly shift over time. My experimental change in how planes are represented reduces the amount of shifting, but doesn't eliminate it entirely. It'll just take longer before you notice it.

 

So it's prolly worth it to track down where the data shifting was introduced and squash it.

 

DR 1.7.2 has the problem, and that's the earliest rev I have.

 

If anyone has older revs they can share, I'd appreciate it. It would make it easier to narrow down where the problem was introduced. In the mean time, I'll see if the repository has older revs stored in it.

 

Whatever rev was in use back in April 2010 did not have the problem, so I don't need revs older than that one, whatever it was.

[nbohr1more 1918]

Older Dark Radiant builds can be found here:

 

http://darkradiant.sourceforge.net/download.php

 

For example:

 

1.2.1 from March 2010

 

32bit:

 

https://sourceforge.net/projects/darkradiant/files/darkradiant/1.2.1/darkradiant-1.2.1.exe/download

 

64bit

 

https://sourceforge.net/projects/darkradiant/files/darkradiant/1.2.1/darkradiant-1.2.1.x64.exe/download

 

 

I think that 1.4 from July 2010 was considered to be a sweet spot release but it's after your target date:

 

32bit:

 

https://sourceforge.net/projects/darkradiant/files/darkradiant/1.4.0/darkradiant-1.4.0.exe/download

 

64bit:

 

https://sourceforge.net/projects/darkradiant/files/darkradiant/1.4.0/darkradiant-1.4.0.x64.exe/download

 

Happy hunting.

[grayman 2781]

Terrific. I can see all the previous releases.

 

I most likely was working with 1.2.1 or 1.2.2 back in Apr 2010.

 

I'll start with 1.3.0 and work forward.

 

Thanks!

[OrbWeaver 482]

For tracking down when a bug first appeared, git bisect is a great tool for the job.

[grayman 2781]

I see a lot of command line instructions on that page. How do I issue those when using Windows?

[grayman 2781]

So I assume I right-click on the main repository folder and ask for Git Bash.

 

That gives me a command line.

 

If I then do

 

$ bisect start

$ bisect bad

$ bisect good vx.x

 

Is vx.x supposed to be v1.5.0 (the last version that I think was good)? Or is it some internal version number that GIT keeps track of? If the latter, how do I obtain it?

[OrbWeaver 482]

Assuming you installed the MSYSGit package, you should have an option in the menus called "Git bash" or something similar. This will popup a bash command window from which you can issue any arbitrary Git command. As I recall the Git bash item appears in the Explorer context menu which allows you to create a bash window that is already in the correct directory.

[OrbWeaver 482]

Is vx.x supposed to be v1.5.0 (the last version that I think was good)? Or is it some internal version number that GIT keeps track of? If the latter, how do I obtain it?

 

Yes, the tags are supposed to identify released versions but I was never thorough about creating them so they can't be relied upon. The best thing to do would be to identify a revision around the time/date of the released version you know to be good, check out that old revision with git checkout <commit-hash> and test to see if it doesn't have the bug. If not, you can set this as the git bisect good revision.

 

I may be able to do some testing in Linux too if the problem is easy to reproduce — are you able to make a simple test map that demonstrates the problem, perhaps with a single brush that has some unusual plane orientations, and then commit this into the maps/test/dr directory in the mod asset repository?

[grayman 2781]

$git checkout <commit-hash>

 

"<commit-hash>"?

 

I've spotted the general area in the commit history where I'd like to begin testing, but don't know how to tell git that's the one I want to check out.

[grayman 2781]

I may be able to do some testing in Linux too if the problem is easy to reproduce — are you able to make a simple test map that demonstrates the problem, perhaps with a single brush that has some unusual plane orientations, and then commit this into the maps/test/dr directory in the mod asset repository?

 

I'll get back to you on that. I have an angled brush I'm working with, but I'm still trying to make sure the problem it's having is the problem described in the op.

[OrbWeaver 482]

"<commit-hash>"?

 

The long hexadecimal number which appears in the commit log, uniquely identifying every commit.

 

commit 04f757d1de1402a45b72789954d031414eb9d4bf
Author: codereader <greebo@angua.at>
Date:   Fri Oct 12 20:55:53 2012 +0200

   The widgets reflect the actual registry values when re-showing a cancelled preference dialog.

 

In the above case the commit hash is 04f757d1de1402a45b72789954d031414eb9d4bf

[grayman 2781]

So once I've identified the hash tag belonging to the last good revision, what number am I supposed to use for x.x below?

 

 

$ bisect start

$ bisect bad

$ bisect good vx.x

[grayman 2781]

$git checkout c1cb017729c4364ad1dc3886845663ffeb358b35

 

Is there a way to copy/paste that string into the bash console? It doesn't accept ^V or right-click->paste.

 

Or am I relegated to typing it in by hand?

[OrbWeaver 482]

So once I've identified the hash tag belonging to the last good revision, what number am I supposed to use for x.x below?

 

You use the hash tag itself, e.g.

 

$ git bisect start

# Set the HEAD (latest) revision as the bad commit
$ git bisect bad HEAD

# Set the last-known-good commit
$ git bisect good c1cb017729c4364ad1dc3886845663ffeb358b35

 

Is there a way to copy/paste that string into the bash console? It doesn't accept ^V or right-click->paste.

 

Good question. In actual Linux you would just highlight it and press the middle mouse button to insert, but I can't honestly remember what (if any) such paste options exist on the Git bash the runs under Windows. You could try Ctrl-Shift-C and Ctrl-Shift-V instead; these are common shortcuts on Linux terminal apps (since Ctrl-C is used to interrupt a process).

[grayman 2781]

Have the win32 support libraries changed since Jan 2011?

 

I checked out what turns out to be 1.5.1, and am getting massive build errors saying win32 files are missing (most often glibconfig.h).

 

I'm trying to build the win32 version. I had no problem building the HEAD.

[OrbWeaver 482]

I checked out what turns out to be 1.5.1, and am getting massive build errors saying win32 files are missing (most often glibconfig.h).

 

That is often a problem with source-based disection: if there were any big build-script/dependency changes in the process, the old revisions may no longer compile. I know Greebo has updated the dependencies in the past (as well as updating the MSVC project files to work with newer MSVC versions), so the bundle downloaded from Github probably won't work with earlier source versions. You are probably best looking in the dependencies SVN repository that is still hosted on SourceForge for the library versions that corresponded to the time period you are trying to build from.

[grayman 2781]

You are probably best looking in the dependencies SVN repository that is still hosted on SourceForge for the library versions that corresponded to the time period you are trying to build from.

 

Where, specifically?

[OrbWeaver 482]

Where, specifically?

 

https://darkradiant.svn.sourceforge.net/svnroot/darkradiant/trunk/w64deps

https://darkradiant.svn.sourceforge.net/svnroot/darkradiant/trunk/w32deps