Re: [Bf-committers] Bringing anti-aliasing back by fixing selection method
Unfortunately, even with glDisable(GL_MULTISAMPLE_ARB), there are still artifacts (at least n nvidia) that break the color coding method. And thus weird things happen, like orphan out of the selection area vertices being selected. Occlusion query is part of openGL standard from rev. 1.5. So it should work well with other cards, but I'm interested to get feedback from ati/intel cards owners... Damien Le 14 janv. 2010 à 06:19, joe a écrit : Though of course rewriting it more properly is good too. I've not looked into occlusion query since the original nvidia extension; how well does it work across disparate video cards? Joe On Wed, Jan 13, 2010 at 9:15 PM, joe joe...@gmail.com wrote: Explicitly disabling it in the selection draw functions seemed to work well enough before, via glDisable(GL_ARB_MULTISELECT). Joe On Wed, Jan 13, 2010 at 8:32 AM, Damien Plisson damien.plis...@yahoo.fr wrote: Hi all, FSAA was breaking border/lasso select operations (e.g. orphan vertices were selected). FYI, The root cause for this issue is that as soon as FSAA is enabled at pixelformat level, even if not enabled afterwards, some color artifacts may appear in draw operations. This breaks the color coding selection method that is currently used in Blender for various selection tools like border, lasso, circle... when occlude geometry is enabled. To fix it, the color coding selection method has to be replaced, and this is what this patch does by implementing the occlusion query method for the border/lasso/circle selection tools: http://projects.blender.org/tracker/index.php?func=detailaid=20660group_id=9atid=127 I'm looking forward for your feedback / comments / suggestions... Damien ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Fixed, and Updated Torus mesh tool
Make a patch and submit it to the patch tracker then give us the link On Thu, 2010-01-14 at 02:40 -0600, Jaevixa McNomera wrote: Hello, I've fixed the descriptions of the properties for the torus mesh in .blender/scripts/op/add_mesh_torus.py Also, i've added 3 new controls to it. The new controls add the ability to specify an Exterior Radius, and an Interior Radius, and then whether or not to USE those dimensions, or the regular Major/Minor Radii values. How do I go about submitting this to blender? Jae ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Michael Fox Developer and user of Blender3d www.blender.org http://mfoxdogg.googlepages.com mfoxd...@gmail.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Fixed, and Updated Torus mesh tool
https://projects.blender.org/tracker/index.php?func=detailaid=20673group_id=9atid=127 is THIS the link i need to give you? I'm really new to this process... :( On Thu, Jan 14, 2010 at 4:28 AM, Michael Fox mfoxd...@gmail.com wrote: Make a patch and submit it to the patch tracker then give us the link On Thu, 2010-01-14 at 02:40 -0600, Jaevixa McNomera wrote: Hello, I've fixed the descriptions of the properties for the torus mesh in .blender/scripts/op/add_mesh_torus.py Also, i've added 3 new controls to it. The new controls add the ability to specify an Exterior Radius, and an Interior Radius, and then whether or not to USE those dimensions, or the regular Major/Minor Radii values. How do I go about submitting this to blender? Jae ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Michael Fox Developer and user of Blender3d www.blender.org http://mfoxdogg.googlepages.com mfoxd...@gmail.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New Developer Meeting minutes
I use msvc for source editing and debugging, and scons for compiling. Build systems don't have to replace project files, I use scons mostly because there's more control that way for what I do. Joe On Thu, Jan 14, 2010 at 2:28 PM, Mike Pan madoni...@gmail.com wrote: As mentioned before, I think one of the key benefit of cmake is the ability to generate solution/project files. This might be not be a huge deal to seasoned coders, but for beginner coders who just wants to explore the Blender source code a bit, having an IDE like Visual Studio really helps. -mike On Thu, Jan 14, 2010 at 2:21 PM, joe joe...@gmail.com wrote: Sounds like us scons people need to try out cmake. See how good it is. I don't have time now, but will try to get to it. Also need to look at how easy it is to maintain, that's one of the really nice things about scons. Joe On Thu, Jan 14, 2010 at 6:04 AM, Miguel A. Figueroa-Villanueva migu...@ieee.org wrote: On Tue, Jan 12, 2010 at 2:51 AM, Mats Holmberg wrote: On 12.1.2010, at 8.39, Nathan Letwory wrote: 2010/1/12 Erwin Coumans: I'm surprised of so much resistance among the Blender developers to such a nice build system as cmake. Thanks, Erwin We can also reverse the question - we have a very nice and working SCons system. Why would you want to get rid of the nice system I created? I'm surprised at the resistance among certain people to such a nice build system as SCons Just to comment on this: I know nothing about the hassle that is required for maintaining any of these systems, but from a Blender user standpoint scons is very easy to use. As Nathan said, I do svn up python scons/scons.py and that's all that's ever needed. During the years, I haven't seen anything being even close to that kind of ease of use. Dont' take that away, please! -mats I'm not a community member, so please pardon the intrusion (I am interested in blender, have compiled it with the cmake system, and I am looking forward to contributing to it in the future, but haven't had the time yet...). However, I just started reading this thread and it seems to me there is a lot of resistance, as Erwin mentions, to cmake without real justification. Although I understand the why, I think the arguments against CMake are not well founded. Most, if not all, of the problems that have been mentioned are related to rules either not updated or wrongly written in the CMakeLists.txt. These are issues with the build system maintainers not with CMake's capabilities. With properly written and maintained CMake files you would have both a very powerful command line based system and an equally powerful IDE based system. For example, the argument of ease of use can certainly be used as a positive aspect of scons, but I find it to be unfounded when arguing against CMake. That is because I do the following version of svn up python scons/scons.py to build my projects, not only on Ubuntu but on Windows: ctest -S simple_ctest_script.cmake With a small script ctest will: update (from svn,cvs,hg,etc), configure, build, test, and submit the build to a dashboard (or any subset of these steps). Again, I don't want to argue against scons, but I think that arguments against cmake are not really flaws of cmake but rather bad experiences because of not knowing how to do things (either from part of the user or the build system maintainer) and not giving it enough of a chance. I think that if the blender community really gives cmake a chance, it will not be dissapointed with the clean, simple, and flexible product that cmake can provide. Whether it should then replace, coexist, etc. with scons is a discussion that I wouldn't feel comfortable providing any input on. Just my $0.02, --Miguel ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New Developer Meeting minutes
joe wrote: I use msvc for source editing and debugging, and scons for compiling. Build systems don't have to replace project files, I use scons mostly because there's more control that way for what I do. And if the project files were updated along with the Scons build files - that is all well good. Seriously, all I am concerned about is the capability of extending debugging Blender in an IDE (namely MSVC XCode being a Windows/Mac guy for graphics). CMake has that by default, being the way it operates, were Scons to provide the project files either automatically or through the use of a command line parameter - I'd be all for it. The slower build time of Scons, while a niggle, is not the issue. It is the disconnect between using/editing Scons using an IDE that is causing myself and the developers I've talked to (an entire two of them :P ) grief. The build of a release version of Blender is not a daily thing. Updating the projects to the latest versions from SVN is such a common task. -- Regards, Benjamin Tolputt Analyst Programmer ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
