Jump to content
The Dark Mod Forums

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

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

: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

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

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

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.

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

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

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

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

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

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

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.

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

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
  • 1 month later...
  • 2 months later...

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.

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.

 

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

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.

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.

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