grayman 2839 Report post 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 Share this post Link to post Share on other sites
Grubber 7 Report post 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 Share this post Link to post Share on other sites
Obsttorte 1440 Report post 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 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
Grubber 7 Report post 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 Share this post Link to post Share on other sites
OrbWeaver 507 Report post 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 Share this post Link to post Share on other sites
i30817 24 Report post 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 Share this post Link to post Share on other sites
Obsttorte 1440 Report post 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 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
grayman 2839 Report post 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 Share this post Link to post Share on other sites
Obsttorte 1440 Report post 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 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
Tels 268 Report post 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 Share this post Link to post Share on other sites
grayman 2839 Report post 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 Share this post Link to post Share on other sites
Obsttorte 1440 Report post Posted January 25, 2013 I thought more about snapping vertices then snapping the planes. Quote 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
Bikerdude 3738 Report post 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 Share this post Link to post Share on other sites
grayman 2839 Report post Posted March 25, 2013 As far as I know, the latest version is 1.7.3, built Jan 6, 2013. Built by Orbs. Quote Share this post Link to post Share on other sites
Bikerdude 3738 Report post 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 Share this post Link to post Share on other sites
grayman 2839 Report post 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 Share this post Link to post Share on other sites
Bikerdude 3738 Report post 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 Share this post Link to post Share on other sites
Bikerdude 3738 Report post Posted June 6, 2013 bump Quote Share this post Link to post Share on other sites
AluminumHaste 946 Report post 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. Share this post Link to post Share on other sites
nbohr1more 1968 Report post 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...) Share this post Link to post Share on other sites
Bikerdude 3738 Report post Posted June 9, 2013 Tried these? Windows only sorryCool will try these tomorrow evening thanks AH. Quote Share this post Link to post Share on other sites
Bikerdude 3738 Report post 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 Share this post Link to post Share on other sites
AluminumHaste 946 Report post 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. Share this post Link to post Share on other sites
STiFU 565 Report post 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 Share this post Link to post Share on other sites
Bikerdude 3738 Report post Posted June 11, 2013 Orbweaver I believe was the last person to work on it. Quote Share this post Link to post Share on other sites
