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

DR and its shifting planes

Recommended Posts

If you're concerned about, or experiencing, translated brushes altering their dimensions or moving off the grid, you can enter vertex mode, select all the vertices, and translate them instead. There's no shifting when points are being moved, just faces (planes).

Share this post


Link to post
Share on other sites

When testing by moving a func_static i find that it deforms a lot more when more stuff has been loaded. So on an empty map the shifting is less than when the same func_static is moved in an existing map. Does this help with troubleshooting?

Share this post


Link to post
Share on other sites

:huh: Well it seemed like a rounding error problem.

 

But if what you're saying is right ...


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

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Share this post


Link to post
Share on other sites

:huh: Well it seemed like a rounding error problem.

 

But if what you're saying is right ...

 

Please don't take my word for it but see for yourself.

 

The ability to create groups of brushes that 'never change' and are easy to clone & move/rotate is one of the best things in radiant i think (if it really works that is). Also because the brush group can be changed back to worldspawn to make a little change is why i love them.

What is also disturbing is the fact that some regular brushes change size when rotating or resizing. See for yourself by creating a x:24 y:8 brush and then vertex-move one corner to get a x:32 brush at one side. Now start to resize and rotate, i get strange values for x like 31.998 and 32.0003. I'm not sure if these tiny changes really matter...but it might be the same problem that is responsible for the bigger changes right?

Also test this first on an empty map and then load a random map to see that now something has changed when doing the exact same tests.

Share this post


Link to post
Share on other sites
Now start to resize and rotate, i get strange values for x like 31.998 and 32.0003. I'm not sure if these tiny changes really matter...but it might be the same problem that is responsible for the bigger changes right

 

Yes, it's floating-point error with the way brushes are stored. It might be possible to special-case it in certain situations (such as the translation-only that was causing the errors on save that are now hopefully fixed), but if you're doing arbitrary transformations like rotation and resizing of brushes there is no way to avoid the error.

Share this post


Link to post
Share on other sites

I think you can increase the precision of FP ops:

 

#include <fpu_control.h>

 

void set_math_double_precision() {

fpu_control_t fpu_control = 0x027f ;

_FPU_SETCW(fpu_control);

}

 

 

from this : http://gcc.gnu.org/b..._bug.cgi?id=323

 

Actually, comment http://gcc.gnu.org/b...cgi?id=323#c109 might be ofinterrest too.

 

edit: looking on further it seems gcc already does this?

Edited by i30817

Share this post


Link to post
Share on other sites

Increasing the precision will only delay the problem but not avoid it. On the other hand it may slow down things.

 

Personally I think we should stick to a method of leaving the nodes on grid for a specified grid size, for example 0.125 or something smaller . Everytime you move a brush or a func_static the editor could automatically snapp all vertices to grid.


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

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Share this post


Link to post
Share on other sites

Personally I think we should stick to a method of leaving the nodes on grid for a specified grid size, for example 0.125 or something smaller . Everytime you move a brush or a func_static the editor could automatically snap all vertices to grid.

 

I'd object to DR automatically snapping to grid after a move. I'd rather be in control of snapping, because two vertices that shared the same coordinates before a move might shift to different coordinates, depending on the geometry of the brushes involved, after the move. Forcing a snap afterward could very well take those two vertices to neighboring, but different, coordinates, even though each is "on grid".

Share this post


Link to post
Share on other sites

Well, the rounding method should obviously be deterministic. So if the two vertices really shared the same coordinates at the beginning and the same operation (translation/rotation) is operated on them they should have the same coordinates afterwards and this should be retained after snapping. :smile:

Edited by Obsttorte

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

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Share this post


Link to post
Share on other sites

Yeah, having an option for "auto-snap" would be really cool. Often you rotate a brush by 90° and end up with a lot of funky rounding errors etc. But it should be optional, especially for the "shrink" option, because this one allows you to build models that have finer details than the minimum grid size (good for exporting small things like keys, trophys etc to ASE models).

 

(As a sidenote, it would be cool if you could zoom in more in DR to view such small details up close).


"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

Share this post


Link to post
Share on other sites

Well, the rounding method should obviously be deterministic. So if the two vertices really shared the same coordinates at the beginning and the same operation (translation/rotation) is operated on them they should have the same coordinates afterwards and this should be retained after snapping. :smile:

 

Not necessarily, depending on the geometry of the brushes. I imagine brush info is kept in plane equations, and one angled plane might be affected differently than another differently-angled plane. If they're supposed to share a common vertex, and the post-move equations shift the vertices away from each other, snapping to grid afterward could move them farther apart, depending on how the rounding occurs on the vertex coordinates.

Share this post


Link to post
Share on other sites

I thought more about snapping vertices then snapping the planes.


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

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Share this post


Link to post
Share on other sites

well.. when I managed to get an internet connection on the train I found that the latest version on the DR sourceforge page is from 02/02/213.

 

So will update the laptop and the desktop to that version.

Share this post


Link to post
Share on other sites

I wasn't aware of that version. Perhaps Orbs checked in some changes but isn't ready to release them yet.

Share this post


Link to post
Share on other sites

Just started working on an old map again and then realised why I stopped, DR and its bloody shifting plains.

 

And the DR on the sourceforge page dated the 02/02/13 is the same as Jan 2013 internal to DR.

 

The shifting plains issue is a royal pain in the arse.

Share this post


Link to post
Share on other sites

bump

 

Tried these? Windows only sorry

 

Guys try this:

 

https://docs.google....dit?usp=sharing DarkRadiant 32bit

https://docs.google....dit?usp=sharing DarkRadiant 64bit

 

Built them a week ago now?

Just checked, darkradiant.exe was built 6 days ago, so a lot newer than what's on the website.


I always assumed I'd taste like boot leather.

 

Share this post


Link to post
Share on other sites

Another option would be to use DR 1.5.1 as that was confirmed not to exhibit this problem as I recall (though you'll lose some performance and features)...


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
Tried these? Windows only sorry

What version are we calling these, 1.7.3.1?

 

[update] its still broken, ass soon as you make a brush an FS and then move it enough the planes shift. The only work around is to make the objects etc out of patches.

Share this post


Link to post
Share on other sites

No just extract the archive to an empty directory and run darkradiant.exe.

No installer.


I always assumed I'd taste like boot leather.

 

Share this post


Link to post
Share on other sites

So is this really still an issue? Oh man! I miss Greebo! :D

 

Sorry anyway for the confusion about 1.8.0 vs. 1.7.3. I was used to the practice to increment the version numbering to the number listed on the roadmap, even for prereleases.

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