Jump to content
The Dark Mod Forums
Sign in to follow this  
grayman

DR and its shifting planes

Recommended Posts

There were two different issues...one was caused by repeated saves, and one was caused by moving. I think only the first was addressed by the new version.

Share this post


Link to post
Share on other sites
Tried these? Windows only sorry

 

I've only used the installer before. Do I just extract this into my current DR folder?

Share this post


Link to post
Share on other sites

You can, it's just a newer build of DarkRadiant, just over write what's there.

A better idea would be to not do that and extract it to a separate folder instead to keep things separated so they don't conflict.


I always assumed I'd taste like boot leather.

 

Share this post


Link to post
Share on other sites

 

and one was caused by moving

 

 

wasn't the workaround for this to grab all the verts before moving instead of grabbing the object or surface?


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

Share this post


Link to post
Share on other sites

Hey all.. Congrats to all on the 2.0 release of TDM! Massive effort and it looks great.

 

Hearing the news got me wanting to maybe do some mapping. Is there any further update on this very troubling issue? A new DR was just released but it doesn't seem to mention it. Is this issue (the remaining one) on the tracker? If it's not, it's a lot less likely to get noticed and fixed.

Share this post


Link to post
Share on other sites

Nnnnope. Just make a grate or any func_static with angled walls in grid1, switch to grid64 and move it faaar up and down few times -and parts will slide for 1,5 points in grid0,125 .

Or grab any custom func_static and make minor mouse move below grid sensitivity -numbers over XYZ bracers will rapidly change.

Edited by ERH+

S2wtMNl.gif

Share this post


Link to post
Share on other sites

There were 2 problems conflated in this thread. One was fixed and the other has a workaround.

Share this post


Link to post
Share on other sites

Yeah, it has been mitigated a lot.

 

*Objects don't deteriorate anymore when saving. They will only deteriorate when you move them (func_static or worldspawn)

*Only weird shaped geometry pieces deteriorate, ordinary 45, 90 degree angles are pretty safe.

*Then the object deteriorates when moving, you can immediately see it is happening, as the object is no longer in solid dimension 4.0 units, but 3.99998 units.

 

*You can go around this by:

1) build strange shapes to the place they are supposed to be, avoid moving them.

2) If you move them, just remember to ctrl-G snap to repair them, before leaving them.

3) you can export complex stuff into .ase models and then they are safe.


Clipper

-The mapper's best friend.

Share this post


Link to post
Share on other sites

Bummer, but at least there are workarounds. I'll be grabbing the new release to see how problematic it is. Last I'm running is 1.6.1 which AFAIR doesn't suffer from it, or my workflow avoids it. I'm rusty, not sure.

Definitely should go up on the tracker IMO.

Share this post


Link to post
Share on other sites

I think as long as DR describes brushes as a collection of intersecting planes (point on plane, plus normal) rather than points, we'll always have this problem. IMHO, floating point errors are going to have a greater effect on the former than the latter, because the former determines the points repeatedly using plane intersection math, every time you open up a map.

 

But I've never worked in DR, and know nothing of its internals, so maybe I'm way off base.

Share this post


Link to post
Share on other sites
Last I'm running is 1.6.1 which AFAIR doesn't suffer from it, or my workflow avoids it.

Welcome back SD,

 

Yes the drifting plains issue is a massive PITA and new mappers will be caught out by this, while the rest of use have gotten used to working around it.

Share this post


Link to post
Share on other sites

Thanks and it's really nice to see so many great people still around!

 

After trying this out last night and confirming (looks like a pretty small effect, but maybe I didn't see it at its worst) I've put this up on the tracker for completeness/anality. I categorized it high priority, but anyone please correct if necessary. I'm late to the show!

 

http://bugs.thedarkmod.com/view.php?id=3571

Share this post


Link to post
Share on other sites

Sikkpin over at Doom3world (using DoomEdit instead of Dark Radiant):

 

 

For a while now, I've been debating the possibility of giving up working with this engine due to brush precision problems that come from the new brush format used in idtech4. Brush planes constantly moving off grid, causing splits and cracks to open up along surface edges, which in turn cause problems with portals, map leaks, and of course, it's just ugly to see, not to mention that hell it causes with my ocd. I couldn't fucking stand it. At first I thought it only affected non-orthogonal faces, so if I ever needed a surface that's not parallel with the grid I'd use a patch. This was cumbersome so I added a bunch of stuff to help with patch creation to speed things up. Moving control points was still slower than edge manipulation, shearing and the clipper tool but it sufficed, until I loaded up a map I haven't touched in a while a noticed a large amount of simple cubic brushes all off the grid causing huge gaping splits.

 

So, fed with the bullshit, I finally said: Fuck it! and dug in to the code to re-introduced the old brush format, like what good ol' Quake used. It turned out it wasn't as much work as I thought it would be and after I was finished, all brush problems have completely disappeared. And best of all is it doesn't affect compatibility with the new brush format and you can still save maps in the new format if need be.

 

No longer do I have to fear the clipper tool or moving edges. No longer do I have to deal with the tedium of patches when not necessary. I can finally map again!

 

Sorry. Just had to let that out. Most probably don't give a shit but this was a huge problem for me.

 

 

http://www.doom3world.org/phpbb2/viewtopic.php?f=13&t=25444&st=0&sk=t&sd=a&start=60

 

He says the old format was still in the Doom 3 code he just had to re-enable it...

Edited by nbohr1more

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

Share this post


Link to post
Share on other sites
He says the old format was still in the Doom 3 code he just had to re-enable it...

Man if Greebo/SD can do the above that would be very much appreciated.

Share this post


Link to post
Share on other sites

Oh hell no, two map formats in one engine is just asking for trouble.

 

Not to mention that his changes are only of much help to him since he's using the build in editors etc.

 

His usecase is simple, ours is really a lot more complex. Fixing the actual bugs in the geometry generation would be a faaaar better solution. I have a nasty suspicion a lot of this actually lies in the vertex lerping stage(s), breaking it into two big areas - should the geometry be generated like that? should it be adjusted at runtime? if so what are the problems in both cases. Specially with faces that are removed from narrow cones.

 

That said, I did some tests dmap ages ago, uncommenting some of the ID code in there which looked (this was not exactly scientific) more correct but had comments about problems. In two cases it fixed void holes being rendered, and closed up a few leaks without any new visible/performance problems. However on complex maps dmap ran even slower - and in the case of two of the campaign maps, failed to ever finish. So I think there is some case for looking at the geom generation first.

Share this post


Link to post
Share on other sites
  • Oh hell no, two map formats in one engine is just asking for trouble.
  • So I think there is some case for looking at the geom generation first.

  • Ah I didnt spot that, bollox :-/
  • Not a total lose then :-)

Share this post


Link to post
Share on other sites

Welcome back SD,

 

Yes the drifting plains issue is a massive PITA and new mappers will be caught out by this, while the rest of use have gotten used to working around it.

 

I thought it was fixed in 1.8.0 where save/load doesn't shift planes any longer.

 

What's the workaround?

Share this post


Link to post
Share on other sites

I thought it was fixed in 1.8.0 where save/load doesn't shift planes any longer.

 

What's the workaround?

 

http://forums.thedarkmod.com/topic/14375-dr-and-its-shifting-planes/page__view__findpost__p__322425

 

I haven't seen any deterioration in my current WIP building.


Clipper

-The mapper's best friend.

Share this post


Link to post
Share on other sites

See Sikkpin's post at Doom3world above... apparently "yes"... though I'm not sure if this applies to non-GPL versions (ie, the version that ships with Vanilla Doom 3).


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

Share this post


Link to post
Share on other sites

See Sikkpin's post at Doom3world above... apparently "yes"... though I'm not sure if this applies to non-GPL versions (ie, the version that ships with Vanilla Doom 3).

 

Thanks, I should have read the thread more closely :P - I have just done some tests myself and found some situations in DoomEdit that lead to shifting planes - it's a lot harder to spot in DoomEdit though because the brush size info is displayed only to the closest integer, so you can't tell when a brush has changed shape unless you zoom waaaaaay in and see that it's off-grid by a tiny amount.

Share this post


Link to post
Share on other sites

I'm just sorting out porting DR to my platform of choice, and I notice that there are a few precision warnings at link time, relating to the map modules and stuff. I assume these are actually fairly tricky to spot due to the way all the modules work, they are not able to resolve the issue at compile time, and at link time stdlibc++ seems to not shout about them. If I get everything working nicely I will see about resolving the symbols and at least reporting them. Might also be worth getting a static analysis, since there are a load of other minor issues around the place.

Share this post


Link to post
Share on other sites

Does anybody have a example for the shifting planes issue including reproducible steps?

Share this post


Link to post
Share on other sites

I tried to reproduce it using angled brushes on empty scene and I couldn't. I need to try again using my massive outdoor map (that's where I got the issue in the first place).

Share this post


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.

Sign in to follow this  

×
×
  • Create New...