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

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


  • Recent Status Updates

    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...