grayman 2982 Posted January 22, 2013 Author Report Share Posted January 22, 2013 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). Quote Link to post Share on other sites
Grubber 7 Posted January 23, 2013 Report Share Posted January 23, 2013 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? Quote Link to post Share on other sites
Obsttorte 1556 Posted January 23, 2013 Report Share Posted January 23, 2013 Well it seemed like a rounding error problem. But if what you're saying is right ... Quote 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
Grubber 7 Posted January 24, 2013 Report Share Posted January 24, 2013 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. Quote Link to post Share on other sites
OrbWeaver 662 Posted January 25, 2013 Report Share Posted January 25, 2013 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. Quote DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts Link to post Share on other sites
i30817 24 Posted January 25, 2013 Report Share Posted January 25, 2013 (edited) 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 January 25, 2013 by i30817 Quote Link to post Share on other sites
Obsttorte 1556 Posted January 25, 2013 Report Share Posted January 25, 2013 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. Quote 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
grayman 2982 Posted January 25, 2013 Author Report Share Posted January 25, 2013 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". Quote Link to post Share on other sites
Obsttorte 1556 Posted January 25, 2013 Report Share Posted January 25, 2013 (edited) 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. Edited January 25, 2013 by Obsttorte Quote 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
Tels 279 Posted January 25, 2013 Report Share Posted January 25, 2013 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). Quote "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
grayman 2982 Posted January 25, 2013 Author Report Share Posted January 25, 2013 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. 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. Quote Link to post Share on other sites
Obsttorte 1556 Posted January 25, 2013 Report Share Posted January 25, 2013 I thought more about snapping vertices then snapping the planes. Quote 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
Bikerdude 3742 Posted March 25, 2013 Report Share Posted March 25, 2013 whats the latest version then, the official one on the dr page or the last one Orbs posted in the previous thread page..? Quote Link to post Share on other sites
grayman 2982 Posted March 25, 2013 Author Report Share Posted March 25, 2013 As far as I know, the latest version is 1.7.3, built Jan 6, 2013. Built by Orbs. Quote Link to post Share on other sites
Bikerdude 3742 Posted March 26, 2013 Report Share Posted March 26, 2013 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. Quote Link to post Share on other sites
grayman 2982 Posted March 26, 2013 Author Report Share Posted March 26, 2013 I wasn't aware of that version. Perhaps Orbs checked in some changes but isn't ready to release them yet. Quote Link to post Share on other sites
Bikerdude 3742 Posted June 1, 2013 Report Share Posted June 1, 2013 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. Quote Link to post Share on other sites
Bikerdude 3742 Posted June 6, 2013 Report Share Posted June 6, 2013 bump Quote Link to post Share on other sites
AluminumHaste 1083 Posted June 9, 2013 Report Share Posted June 9, 2013 bump Tried these? Windows only sorry Guys try this: https://docs.google....dit?usp=sharing DarkRadiant 32bithttps://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. Quote I always assumed I'd taste like boot leather. Link to post Share on other sites
nbohr1more 2237 Posted June 9, 2013 Report Share Posted June 9, 2013 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)... Quote 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
Bikerdude 3742 Posted June 9, 2013 Report Share Posted June 9, 2013 Tried these? Windows only sorryCool will try these tomorrow evening thanks AH. Quote Link to post Share on other sites
Bikerdude 3742 Posted June 11, 2013 Report Share Posted June 11, 2013 Tried these? Windows only sorryWhat 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. Quote Link to post Share on other sites
AluminumHaste 1083 Posted June 11, 2013 Report Share Posted June 11, 2013 No just extract the archive to an empty directory and run darkradiant.exe. No installer. Quote I always assumed I'd taste like boot leather. Link to post Share on other sites
STiFU 766 Posted June 11, 2013 Report Share Posted June 11, 2013 So is this really still an issue? Oh man! I miss Greebo! 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. Quote Link to post Share on other sites
Bikerdude 3742 Posted June 11, 2013 Report Share Posted June 11, 2013 Orbweaver I believe was the last person to work on it. Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.