Jump to content
The Dark Mod Forums

DR and its shifting planes


Recommended Posts

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. :P

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 by Obsttorte
  • Like 2

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 post
Share on other sites
  • Replies 242
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

New builds have been uploaded which should no longer exhibit this problem. The links are the same as before:  

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

Yeah, it exports the selection you have into a model. The model cannot be changed anymore so it is DR object corruption bug immune. Downside is you need to export it again if you want to change it lat

Posted Images

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.

Link to post
Share on other sites

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.

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 post
Share on other sites

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.

Link to post
Share on other sites

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.

  • Like 3
Link to post
Share on other sites

And buy Obstorte a beer :P

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to post
Share on other sites

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

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Link to post
Share on other sites

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 by Obsttorte

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 post
Share on other sites

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

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 post
Share on other sites

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

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

Edited by Obsttorte

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 post
Share on other sites
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.

Link to post
Share on other sites

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.

Link to post
Share on other sites
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.

Link to post
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.


×
×
  • Create New...