Jump to content
The Dark Mod Forums

DR and its shifting planes


Recommended Posts

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

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

I'll try that.

 

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

 

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. ^_^

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

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

 

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.

  • Like 1
Link to comment
Share on other sites

well, that would be the second suggestion than

 

anyways, someone has to implement this

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

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"

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

"<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

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...