Object Corruption in DR

[grayman]

Well, I can't find the thread where greebo posted the latest version of DR with the change from float to double, so I'm posting my comment in a new thread. I'm using this latest DR version.

 

Is there anything at all that can be done about the problem of DR's math corrupting objects?

 

Here is a fresh copy of one of the Cabinet prefabs. Note the nice way the faces meet on the highlighted block at center screen.

 

 

Now here's the same cabinet after a week of DR sessions. Note how the highlighted block's faces have started moving. In a couple months, the block will be completely gone (it happened to me, which caused me to refresh all my cabinets last week).

 

[Springheel]

Here's the original thread: http://forums.thedarkmod.com/topic/13948-weird-list-of-getpointousideobstacle-errors/page__view__findpost__p__291091

[Bikerdude]

yeah I also noticed this months ago when working on WH, I hope it gets fixed as its a big show stopper for a mapper.

[SeriousToni]

What? Did it happen while opening / closing the map or while moving the object?

[grayman]

What? Did it happen while opening / closing the map or while moving the object?

 

It's from opening/closing the map repeatedly.

[stumpy]

darkradiant seems to see .0000 as .0004, and after a while it become .0008, .0016, .0032, .0064, .0128, etc till it corrupts func_static objects

 

but just moving func_static objects seems to cause them to go corrupt (this is brushes that have been changed into func_static objects)

[Sotha]

Oh, so *THAT* explains it!

 

Back when I was working on phrase book, I noticed that some roofs I had constructed started deform in a subtle yet weird manner. I had a roof with two brush components. I had caulked the unseen sides where the slants joined. I was sure the roof was okay and cloned it around. And at some point the caulk came visible in game. I thought I had made some weird mistake. Eventually I just applied the textures onto the whole roofs instead of fixing the geometry that was subtly broken in unknown amount of roofs. So it was some weird rounding error in the end!

 

This is something ultra-critical which needs an emergency-patch soon.

[nbohr1more]

This might also explain some of the z-fighting problems in St Lucia beta... (patches no longer correctly offset from surfaces)?

[Springheel]

This might also explain some of the z-fighting problems in St Lucia beta.

 

Biker is the only one seeing z-fighting with patches. Not sure what's up with that, but quite possibly a 1.08 renderer glitch.

 

The floating point issue did cause a different headache though.

[greebo]

If grayman is using the one experimental build I posted in the internal forums, then DarkRadiant is basically behaving like the pre-1.6.0 versions (before I switched to single-precision floats for performance reasons). Can't do more than that at the moment, I'm pretty burnt out on coding, so if somebody else wants to take a look: be my guest. Don't wait for me to fix it.

[grayman]

If grayman is using the one experimental build I posted in the internal forums, then DarkRadiant is basically behaving like the pre-1.6.0 versions (before I switched to single-precision floats for performance reasons).

 

That's the one I'm using. The plane shift shown in the OP occurred while using only this version of DR. The plane shifts I've seen over the past year+ were (of course) caused by the versions of DR available over that time.

[RPGista]

I had this problem often, it seems to happen mostly on small brush solids (I have plenty in my map, things like fences, wood planks, it even ruined my stair railing, I now see - there are several corruptions that actually made past my eyes and are in the released map right now). Just to make sure, the latest release (1.7.2) shouldnt suffer from this problem, is that right? Or is it common to all versions?

Edited August 7, 2012 by RPGista

[grayman]

Just to make sure, the latest release (1.7.2) shouldnt suffer from this problem, is that right? Or is it common to all versions?

 

1.7.2 has the same problem.

[Tels]

As I'd said in the other thread, the real solution here would be to sort of "freeze" the planes from brushes read at map start, and write out exactly these when the brush has not been touched in the editing session. So if it starts with 0.0000000001, it stays at 0.0000000001 forever.

 

Converting the brush planes to vertices, then converting them back at write and then writing out the value is what causes the corruption, and no amount of precision in the float/double/whatever values you use can prevent this, the best you'd only be able to achive is to make the corruption very small - but a 100 reads+writes would still ever so slightly move things away.

 

But I don't have access nor experience with the DR source tree, so I can't fix this at all. Maybe someone else can.

[Tels]

I did look at the map file format http://www.modwiki.net/wiki/MAP_%28file_format%29 , and noticed the following:

 

For brushDef and brushDef2 brushes, the plane is defined by a triangle instead:

( p1x p1y p1z ) ( p2x p2y p2z ) ( p3x p3y p3z ) ( ( xxscale xyscale xoffset ) ( yxscale yyscale yoffset ) ) "material" ?

 

 

It is abit unclear:

 

* can one simply exchange brushDef or brushDef2 for brushDef3?

* what is the difference between brushDef and brushDef2?

 

If these formats can be interchanged at wil, then maybe it would be better that D3 writes out the version with the 3 triangle points instead of the one with the face equations,and maybe this would fix the corruption occuring due to multiple saves?

[Bikerdude]

1.7.2 has the same problem.

I thought orbweever was doing the 1.7.2 rollout..?

[grayman]

I thought orbweever was doing the 1.7.2 rollout..?

 

So did I, but he's disappeared.