[Bf-committers] python tangents export missing
I see rumblings now and then here and there about Blender's python API missing the ability to export Blender's internal tangent space. http://www.blender.org/forum/viewtopic.php?p=105835sid=68eaa02463462a62bbdcbe427761ca49 There's also been a proposed patch around for a while: https://projects.blender.org/tracker/index.php?func=detailaid=29335group_id=9atid=127 I just thought I'd bring it up in case anyone has the knowledge and bandwidth to perhaps pick it up. Cheers, Morten. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [58752] trunk/blender/source/blender/ editors/object/object_bake.c: Fix #36302: Multires baking to zero 0 was showing error but st
I just wanted to say I think that sounds like a great idea. Cheers, Morten. On Sat, Aug 10, 2013 at 10:26 AM, Antony Riakiotakis kal...@gmail.comwrote: Either make the strokes touch mesh data directly, or use an apply base modifier prior to baking, maybe with a warning that baking will alter the mesh data. Make that an Apply Base operator instead of modifier, sorry for the confusion ___ 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] Object space normal map axis proposed change.
This could be done of course but there are some problems like the fact that the object space map doesn't necessarily come from file. It could be procedurally generated or just a bake in which case the sampler isn't supposed to swizzle. Also the texture sampler at least at this point in time doesn't know if it's an object space or a tangent space normal map. So though it can be done someone would have to work out all the corner cases. On Fri, Jun 14, 2013 at 2:16 AM, Andy metalliandy...@googlemail.com wrote: Yea, I think that this would also be a great idea. It would also good for the tangent space map too so that people can flip the green (Y+ to Y-) for when they are using game engines such as UDK or CryENGINE. On 14 Jun 2013, at 09:58, Fredrik hansson fredrikhansson_12...@yahoo.com wrote: a better option imo would be to give 3 small dropdown boxes under the object space selection or somewhere similar to the user where you can pick what goes where so you set it to match your target application From: metalliandy...@googlemail.com metalliandy...@googlemail.com To: bf-committers@blender.org bf-committers@blender.org Sent: Friday, June 14, 2013 10:50 AM Subject: [Bf-committers] Object space normal map axis proposed change. Hy everyone, I would like to propose a change the the axis configuration that is currently used when baking to object space normal maps. What does everyone think about changing it so that the axis matches the one for the tangent space normal maps (X+ Y+ Z+)? Currently the OS maps use a very odd configuration so if anyone wants to use them in other applications, or as something like a selection/direction mask while texturing, they have to do some very complicated channel flipping and swapping within Photoshop which is confusing even to experienced users. Cheers, -Andy ___ 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] MSVC2010 maintainer? Python 3.3 libs missing, or only me?
Good idea. Let's drop VS2008 :) Cheers, Morten. On Sun, Mar 17, 2013 at 3:32 AM, Thomas Dinges blen...@dingto.org wrote: Hi, I was never a fan of those mixed repositories, and the few vc2010 libs we have only work with cmake as well. Whatever we do, one day we really need to get rid of the old VC2008 crap... Most Blender users use Windows and we use a 6 year old compiler here. I have no idea if current VC20112 is better, produces faster code etc, but there must be something that we can do. It always hurts when I compare Blender Render performance between VC2008 and GCC/MinGW :/ Best regards, Thomas Am 17.03.2013 05:40, schrieb Alexandr Kuznetsov: Hi. I think we can drop vc10 for several reasons: 1) No one actively maintains it. 2) Visual Studio 2010 works fine with regular libs if vs2008 is installed. Also all c-only libs are working perfectly with all compilers! C++ lacks standard ABI afaik. 3) VS 2012 Personally, I switch to 2012 version (after disabling Cap Locks menus). Most libs work fine. Also, I think we should support only x64 for non standard compilers (aka not vc2008). People who download custom builds, probably have modern x64 system. It was 5 years of windows x64 (not counting xp). Best, Alex. On 3/15/2013 7:28 PM, Dalai Felinto wrote: Hi, is there any update on this? If we can't have all the libs working for vc10 I propose we simply drop support for msvc10 and remove the other libs for vc10 that are already in the repository. Better than mislead people to download the libs and frustrating them with a half-working setup. Thanks, Dalai blendernetwork.org/member/dalai-felinto www.dalaifelinto.com 2012/12/23 Chad Fraleigh ch...@triularity.org And to be thorough, the VS2012 scripted builds I could manage at this time: http://www.triularity.org/download/blender/install-vs11.0-x32.zip (141M) http://www.triularity.org/download/blender/install-vs11.0-x64.zip (154M) install-vs11.0-x32: boost freetype jack jpeg lcms llvm openal png python samplerate sdl sndfile tiff zlib zlibwapi install-vs11.0-x64: boost jack llvm openal png sndfile tiff zlib zlibwapi -Chad ___ 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 -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ 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] MSVC2010 maintainer? Python 3.3 libs missing, or only me?
Errr...I actually use msvc2010. Whatever contributions I've made to blender have been from a vs2010 setup. It's still how I build blender. On Fri, Mar 15, 2013 at 4:28 PM, Dalai Felinto dfeli...@gmail.com wrote: Hi, is there any update on this? If we can't have all the libs working for vc10 I propose we simply drop support for msvc10 and remove the other libs for vc10 that are already in the repository. Better than mislead people to download the libs and frustrating them with a half-working setup. Thanks, Dalai blendernetwork.org/member/dalai-felinto www.dalaifelinto.com 2012/12/23 Chad Fraleigh ch...@triularity.org And to be thorough, the VS2012 scripted builds I could manage at this time: http://www.triularity.org/download/blender/install-vs11.0-x32.zip (141M) http://www.triularity.org/download/blender/install-vs11.0-x64.zip (154M) install-vs11.0-x32: boost freetype jack jpeg lcms llvm openal png python samplerate sdl sndfile tiff zlib zlibwapi install-vs11.0-x64: boost jack llvm openal png sndfile tiff zlib zlibwapi -Chad ___ 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] Texture painting considerations (preparations for bratwurst merge)
That's ok, as long as you admit that you were wrong :) (kidding) On Mon, Mar 4, 2013 at 7:02 AM, Antony Riakiotakis kal...@gmail.com wrote: My previous answer is wrong it seems. It looks like when using the space stroke option, the two modes (projective/2D) operate slightly differently. Spacing is done on image/uv space for image editor and screen space for projective texturing. That means that most of the time, the 2D code will generate many more strokes per pixel than the projective case (because generally texture is zoomed out in viewport). This has the effect of getting a more intense result when painting in the 2D view. I wouldn't count this as a bug though, it is intended behaviour. ___ 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] Proposed default margin increase for baked textures
Go for it! :) On Sun, Mar 3, 2013 at 7:01 PM, Antony Riakiotakis kal...@gmail.com wrote: This is trivial but will require yet another version patch. If others agree I could commit it wit h a value of 16. ___ 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] Texture painting considerations (preparations for bratwurst merge)
Perhaps you could also look into why the default brush looks so bad for bump painting yet when air-brush is checked it looks perfect. Just a though :) Cheers, Morten. On Sun, Mar 3, 2013 at 6:17 PM, Antony Riakiotakis kal...@gmail.com wrote: Hi all, an update on this thread. Currently I am in the process of reusing paint stroke code in texture painting. The experiment is being a success but to unify the code better I will need to tweak code across other paint systems too and gather feedback. Considerations and things that I personally want to refactor are: Texture painting === * Disentangle projective and 2D painting completely. The only shared code is the stroke calculation code parts of which are duplicated in paint_stroke.c and indeed should be written once and reused on all our paint systems. This would be easier if we get rid of 3D (non-projective) mode texture painting in 3D viewport. In this mode you paint on model but result gets written in image space and will be horribly distorted in 3D view. In my opinion this is useless since we now have projective texturing for all tools (blur, smudge, clone, draw) and view mapping mode is exposed. There has been one user complaint about using pixel size of brush in 3D space which is possible in this mode but I think 3D viewport is not the editor for working in image space. On the contrary, painting on image editor is recommended and produces better feedback. * Reuse paint stroke code. This is possible currently but we do some pressure manipulation in the paint code that needs to move to the generic stroke code. Doing this in the stroke system will require reviewing all our paint systems and modifying them not to do extra conversions on the pressure. We need to define better what state the pressure values are during stroke/initialization etc. Other modes = * On almost all modes I checked (texture painting included), we use mouse coordinates in region space (the update_step functions all subtract the region coordinates from the mouse coordinates). Paint stroke code operates in screen space. I think this is only used for sculpting? Are there any objections to tweaking the code to use region space? * Pressure manipulation code should move to paint_stroke (any objections/special cases here?) * Brush texture sampling: Currently there are many methods to do this. Some are used in texture painting, 2 methods, one each for projective and 2D case and one is used for sculpting (where we convert the result to intensity). Ideally the way this should ideally operate is that we pass screen coordinate or 3D position for some brush modes to the brush texture sampling function and the function should return the corresponding texel value based on the brush settings. This should ideally be a global interface in BKE_brush. I think I could probably refactor the sculpt sampling function to something more global. I won't be able to unify the 2D paint code to use that (because input coordinates are in uv, not screen space) but this will allow us to expose texture sampling for all 3D paint modes see vertex paint, even weight paint too. Also it will allow me to implement a stencil mapping mode (like the one done by Nicholas Bishop in his ptex branch) and expose it to all 3D paint modes at once. * Almost every paint mode uses variables like first, to do first time initializations, be it tool or mode specific and last_mouse. paint stroke stores these too. Maybe they could be reused? I am waiting feedback on these from all paint system maintainers. If this is to be undertaken I could possibly do most of the code work but I'd like some good testing for corner cases that may break, which is bound to happen for certain in this kind of refactoring. ___ 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] Collecting fixes for 2.66a release.
Sergey did a fix such that the dilated region outside a displacement map isn't very dark. Without it you get really bad filtering seams. Perhaps sergey can chime in? Cheers, Morten. On Sat, Mar 2, 2013 at 2:47 AM, Dalai Felinto dfeli...@gmail.com wrote: Hi Campbell, Due to some bad timing, most of the intensive testing we were planning for 2.66 ended been done after 2.66 was out. That's not ideal, but I prefer taking changes of having animation or multi uv system not working, than the certainty of they not working (as it is in 2.66 now). So those are my suggestions (on top of yours): ==Trunk== 54745, 54757, 54759, 54766, 54769, 54772, 54777, 54828, 54922 + patch from #34428 ==Trunk(MAYBE)==: 54806, 54813, 54814, 54815 The explanations: = dfelinto: 54745 (alpha for other OSs - it works for OSX, this patch make it work for others) + [ gaiaclary: 54747 (buidfix) ] ((maybe that's the one you mistyped as 54754?)) 54922 (rst update) moguri: 54772 (definitively - no brainer) 54766 (animation fix) 54769 (animation fix part 2) 54777 (material anim port) - may be a MAYBE, but I think it's a safe and needed one. 54828 (harmless, removing excessive warning from console) patch on #34428 (to be committed asap by Mitchell) http://projects.blender.org/tracker/index.php?func=detailaid=34428group_id=9atid=306 [final fix for the multi-uv problems. I've been testing it and it's good. But I'm waiting for Mitchell to commit it] sergof: 54757 (that fix a segfault iirc) alexku: 54759 (fix for windows size on windows) MAYBE: (I'm not in X11, so I didn't try it, but it does seem as an important, no?) campbell: 54806 (fix for fullscreen on X11 - BGE) psy-fi: 54813: (same/complement of 54806) 54814: (same/complement of 54806) 54815: (same/complement of 54806) -- Dalai blendernetwork.org/member/dalai-felinto www.dalaifelinto.com 2013/3/1 Campbell Barton ideasma...@gmail.com Hi I went over commits since release and make a suggested list of changes to be included in 2.66a. There are some areas I'm unsure of: * Mougri's BGE animation fixes (mixed in a bit with refactoring). * Aligorith made some animation fixes after fairly large commits to animation code. * Sergof's Bullet/Physics are mixed with features and fixes. need feedback which are safe for release. * Cessen made changes/fixes to Rigify. == Revs Checked == Trunk: 54697 -- 54965 Ext: 4315 -- 4336 Arranged by name so authors can check on their own work since last release. == Trunk == dfelinto: 54733 54754 54912 moguri: 54738 54764 54767 54780 54837 nazgul: 54746 54748 54901 54934 54935 54946 54947 54960 blendix: 54760 54793 54868 54885 54942 54943 54944 54945 54959 54965 campbellbarton: 54776 54781 54783 54824 54833 54834 54835 54865 54866 54875 54877 54878 54879 54882 54883 54899 54900 54903 54907 54917 54920 54921 54923 54928 54929 psy-fi: 54788 ton: 54789 54790 54794 54816 54908 54910 54954 54961 nicholasbishop: 54827 gaiaclary: 54856 == Trunk (MAYBE) == dingto: 54948 aligorith: 54924 54926 54927 sergof: 54757 54799 54822 54855 54862 alexk: 54761 moguri: 54769 54772 gaiaclary: 54888 mont29: 54891 nazgul: 54904 54937 === Ext == campbellbarton: 4320 4325 4327 cessen: 4321 4334 4335 - Campbell ___ 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] Proposed default margin increase for baked textures
I agree completely. I think the default of 2 might have been set by someone who didn't take mip levels into account. To be honest I generally use 32 or 64 as margin depending on texture size (larger texture means more mips). But I suppose 16 as default which I think is also what it is in xNormal seems reasonable. At the very least I'll echo that 2 is no good :) The background color will bleed into the subsequent mip levels too quickly. Cheers, Morten. On Fri, Feb 22, 2013 at 9:18 PM, metalliandy metalliandy...@googlemail.comwrote: Hey everyone, I want to propose a change the default margin value that is currently used when baking textures. The current margin of 2px is no where near enough and really doesn't help anyone due to the fact that it only is enough for the initial baked texture and not for any further mip levels that may be needed. As I'm sure some of you may be aware, you need at least 1px of margin per UV island to be correct for each mip map level as the texture is resized down, in order to stop the background colour from bleeding into the UV islands. I would recommend using a value of 16px as the new default as this would allow for 3 mip levels in addition to the initial bake, as long as the background colour is correct) which should be enough in most cases as the texture is resized down (16px8px4px2px). Ideally of course we would set the margin so high that there is actually no background colour, but I don't think that many people would go for that as some feel that it makes the texture look messy, however irrelevant this may be, some people do care about how their textures look even if you will never see margin on the final mesh. ;) Please take a look at the link below for an example of what an incorrect margin value can look like when viewed on your mesh. http://blenderartists.org/forum/showthread.php?279870-seams-artifacts-with-tangent-normal-map-in-blender-and-unity For clarification, this is applicable to all baked textures, not just normal maps Cheers, -Andy ___ 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] Minimal Blender specs - 5 year old systems OS
Just wanted to say though I'd like to make it a min. requirement for blender to support pixel shaders last I checked I wasn't kickin it with the Rockafellas :) I also want to echo what campbell said that blender runs very well on sub $500 systems which btw support pixel shaders. I also want to point out that very few developers work on blender full-time and let's face it less sexy work like legacy platform support will most often end up in their hands. Furthermore, Blender is expected to run on all new generations of OSes so it seems only fair to me that subsequently they'd phase out older OSes if there is a need to do so. I know more about graphics than OSes though so whether or not this is the case is not for me to say. If they don't have the resources available to manage it then I feel we all have to respect that. As developers they also deserve time to work on features/functionality and not get wrapped up in perpetual maintenance. That being said if there is some special interest group that feels as strongly about it as you do then obviously, as was already said, could handle such a task. I do like the idea as much as anyone that blender can be a path for anyone and at any age to enter the community and maybe even the industry eventually. However, not to the extent that I'd be willing to sacrifice functionality for higher end developers (in terms of abilities as an artist). As long as that's not the case I am on board with striving to serve more people. I guess it's a balance. But ultimately I value features and functionality over support for legacy hw. That's my 2 cents anyway. Cheers, Morten. On Fri, Feb 1, 2013 at 5:55 PM, Chad Fraleigh ch...@triularity.org wrote: On Fri, Feb 1, 2013 at 3:31 AM, Ton Roosendaal t...@blender.org wrote: I don't think this response justifies the careful and positive way everyone who works on Blender is handling this topic. But I realize it might not be well visible whether people who talk here are also contributing to Blender though. Knowing all of the active devs here quite well, I can only ensure you they're all very responsible, and proud to contribute to a program that runs on nearly everything. But we have to cope with open source dynamics, which depends on the singular fact that nothing happens without people contributing to it. That's democratic fair. I have nothing against the blender developers.. in fact I've been trying to help and _be_ one of those developers (part time anyway). It is just that when someone makes a comment that seems to imply play with blender if you like, but if you're serious and don't have _real_ hardware, then don't bother, it comes off a little insulting.. especially for those that don't try to keep up with Joneses, so to speak. This is what I was trying to point out that _IF_ such a view was applied to an open source project (like blender), then interest in contributing would drop. Letting blender do new and great things, giving the average user the potential to create amazing things (and without shelling out an insane amount of money for Maya) is the best goal.. but alienation effects (which will always happen no mater what) should be balanced in. And I know I'm not anywhere near the best professional grade user of blender in the world, and it took me a long time to get the hang of it. When I first started I would try it for a while, learn all the [effectively] minimum shortcuts, then stop for awhile, and then had to relearn all the shortcuts I forget. Mostly this was because there was a bug in my laptop video driver that would lock up the system about %80 of the time I used the selection box (B), followed by a hardboot, and filesystem check. There was no driver update available and being a laptop I couldn't install a new video card. I even tried running an Xserver and displaying blender back from my BSD box, but hit the same bug. Eventually when I did get a new laptop, part of the criteria was it _had_ to have a keypad and not use the same series video card, so that I could run blender without the problems (see.. that's how much I like blender!). For non-developers this 5 year guideline might seem arbitrary or unclear, but for everyone who's been working - especially on support and bugs - it's a growing frustration that we can't help people anymore using old hardware or OSes. Also... developers and users also want the best product possible, utilizing current hardware and OS developments. To balance this I proposed this guideline, which still offers a far better platform support you'd get from any commercial 3d software. Maya wouldn't even be supported 5 years ago on systems we still do! At some moment people who are stuck in the past with hardware, also need to accept they cannot get new software for it either. We will do our very best here, but in cases where support is really impossible we can use the proposed guideline to define what to do. If
Re: [Bf-committers] Minimal Blender specs - 5 year old systems OS
I just wanted to say that I too agree that we should assume some higher level opengl. I think it would be rather helpful in fact if we didn't rely on traditional fixed function rendering period but instead keep it simple such that we're always using custom shading. It keeps it simpler, easier to maintain, and encourages people more to dive into special kinds of shader dev which I know for instance we'd like to have for sculpt mode. For instance our options when it comes to viewing a sculpt in FLAT vs. SMOOTH shading are significantly different with pixel shaders than without. We are currently passing the mesh (which is typically many millions of triangles) to the GPU as unindexed to support FLAT in the fixed function rendering pipeline. That's just one example but generally speaking I think it would make maintenance and better support easier for that end of the code if we abandoned the fixed function rendering pipeline and went fully custom shader as has been the trend for years now. I think OpenGL 3.2 makes sense but not a deal-breaker :) On Thu, Jan 31, 2013 at 8:25 AM, Jed Frechette jedfreche...@gmail.comwrote: FWIW, I see 3D content creation as a fundamentally high-end endeavor. Being able to start learning Blender on low-end systems is great. However, I want Blender to be taken seriously as a professional tool, not just something you play with until you are able to afford real hardware and software. If development is being held back by attempting to support old hardware and OS versions and no one is willing to step up and support those bits then their use should be depreciated.I would much rather see the limited developer hours available put towards moving Blender forward rather than attempting to maintain compatibility with an ever increasing list of legacy hardware and OS versions. -- Jed Frechette ___ 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] Minimal Blender specs - 5 year old systems OS
If development is being held back by attempting to support old hardware and OS versions and no one is willing to step up and support those bits then their use should be depreciated.I would much rather see the limited developer hours available put towards moving Blender forward rather than attempting to maintain compatibility with an ever increasing list of legacy hardware and OS versions. Wow I couldn't have said it any better and I couldn't agree with you more. Carrying around such legacy hw/apis can and does get in the way of catering to the needs of higher end developers. Besides we're not talking about requires 8 cores and 8 gigs of gpu memory. We're talking about a fairly reasonable up-tick in min. spec in my opinion. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] MSVC2010 maintainer? Python 3.3 libs missing, or only me?
Doesn't matter if it's win32 or win64. Either way the pyth3.3 libs are missing for vs2010. On Wed, Dec 19, 2012 at 11:15 AM, Dalai Felinto dfeli...@gmail.com wrote: New round of errors: http://www.pasteall.org/38201 It's actually the same as before but instead of complaining about LIB Debug|x64 been invalid, it complains of Debug|x64. One thing that strike me as a surprise is that Freetype build folder is named win32. Isn't this suspicious? I'll try to build for 32, since 50/50 is better than nothing. Now you can also poke me on irc (dfelinto) if you want to run tests together (to avoid cluttering the list and all). -- Dalai On Tue, Dec 18, 2012 at 3:00 PM, Chad Fraleigh ch...@triularity.org wrote: On Tue, Dec 18, 2012 at 9:40 AM, Dalai Felinto dfeli...@gmail.com wrote: Hi Chad, Thanks for waving in. I get the following error after commenting the proper lines for x64/vc2010 and installing Python 2.7: http://www.pasteall.org/38156 Yeah, unless you're compiling for 2008 there's only a 50/50 chance it will work at the moment.. and if doing x64, even less. It seems that freetype doesn't come with an x64 platform config for visual studio. This is one of those I've gotta eventually hack the configuration things (and at this point I have no idea how to add x64 to one). Anyway, on a side note there was a couple makefile fixes, one for the 2010 freetype project (that uses that standard Debug/Release names, unlike the 2008 one which used LIB Debug/LIB Release. Also I fixed the install for python x64 (since the project builds into an amd64 subdir for some reason). Anyway, this file should replace the one under build/Makefile.nmake: http://www.triularity.org/download/blender/Makefile.nmake Also, since I still don't have a working 2010 x64 environment (stupid M$ - I guess they didn't want people to easily make modern software for their OS), I have to use 2012 x64. But between 2010 x32 and 2012 x32/x64, hopefully it will be enough for me to make a usable builder script even for 2010 x64. -Chad ___ 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] Triangulate modifier
I don't think you're correct. The gl code receives quads. It's arbitrary what happens to the quads once opengl gets them. The modifier will enforce correctness. On Wed, Nov 14, 2012 at 1:10 PM, CoDEmanX codem...@gmx.de wrote: OBJ exporter offers a Triangulate Faces option. If enabled, it won't export quads, but take the tessfaces and turn quads into tris by using vert 0,1,2 for one tris, and 2,3,0 for another. This way, you get what you see in viewport, non-destructive and without extra calculations. Search for f_v_iter: https://svn.blender.org/svnroot/bf-extensions/trunk/py/scripts/addons/io_scene_obj/export_obj.py Am 14.11.2012 21:31, schrieb Morten Mikkelsen: The important thing is that any proposed solution will work with export too. If the obj exporter is still exporting quads and beyond then this is not a solution. The modifier solution will make sure the exporter when exporting the dm exports the same triangulation. If what you are proposing does that then it's probably fine. On Tue, Nov 13, 2012 at 4:07 PM, Brecht Van Lommel brechtvanlom...@pandora.be wrote: Tessfaces contain both quads and triangles. The render engine can store quads natively (uses less memory) and has its own splitting algorithm which is different than what OpenGL does. Perhaps it would not be a bad thing to add an option to Mesh datablocks to disable that smart render engine splitting and have it the same as the viewport, and enable it by default even. I don't know how important the smarter splitting it is in practice, in Cycles I intentionally did not add it because it can pop in animation and be inconsistent with the viewport, did not see complaints about it so far. Brecht. On Wed, Nov 14, 2012 at 1:00 AM, CoDEmanX codem...@gmx.de wrote: Alright, maybe what i had on mind isn't possible in your case. As Blender has a tessface cache, I thought it should be used throughout the application for everything that requires tessellated mesh geometry. Polygon and tessface data can be accessed at the same time, so this is basically non-destructive as well. What is missing IMO is a checkbox to toggle display of tessfaces (we already see tesselated faces, but they aren't outlined etc.) A modifier might offer an extra ability of editing the triangulated mesh non-destructively, not sure if possible, but if so, it would be great to be able to adjust triangulation in certain spaces (tessfaces don't make up nice triangles) Am 14.11.2012 00:25, schrieb metalliandy: The point of the modifier is not how it is triangulated, it is that the triangulation is non destructive and can be visibly toggled on and off by the user at will and without the need for undo steps :) Also that quote you was from me, not Morten and I was 100% accurate. Morten replied and said in his reply to me This is not exactly the issue. Let me clarify. The mikktspace part is done at quad level if there are quads and will always give the same tangent spaces at vertex level no matter what the order of vertices or faces is. This is its very strong advantage which other tangent space calculators can't do. After mikktspace has already run the problem occurs at a later stage because before rendering/baking triangulation has to have been performed. So the issue is eventhough the tangent spaces at the vertices aren't impacted by how quads are triangulated (since triangulation happens later) the interpolated tangent space is heavily impacted by which diagonal is picked. Similar to how Gouraud shading is heavily impacted by which diagonal is picked. So eventhough tangent space is consistent at the vertices you get problems if baker and render don't pick the same triangulation due to differences in the interpolated tangent space. I should mention I am using render triangulation loosely here since it can happen in a lot of places though for a game it would typically happen somewhere in the engine's tools pipeline. Anyway the advantage to this modifier is it enforces a consistent triangulation which will be received by both baker and renderer (incl. Blender's renderer). Further, this is achieved without causing permanent triangulation. It's a sensible practice which is already used by artists in other modeling products. Morten M. I hope that clears everything up :) -Andy On 13/11/2012 23:12, CoDEmanX wrote: Sounds to me like there is an inconsistency somewhere in Blender, which causes the difference in mesh geometry between what baker uses and the stored/exported data... Shouldn't everything in Blender use tessfaces, if triangles are required? When baking with an all quad mesh, the triangulation that is done internally in Morten's TS might not match the manual triangulation that the user applies on export [...] - Morten Mikkelsen There shouldn't be manual
Re: [Bf-committers] Triangulate modifier
The important thing is that any proposed solution will work with export too.
If the obj exporter is still exporting quads and beyond then this is not a
solution.
The modifier solution will make sure the exporter when exporting the dm
exports the same
triangulation. If what you are proposing does that then it's probably fine.
On Tue, Nov 13, 2012 at 4:07 PM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
Tessfaces contain both quads and triangles. The render engine can
store quads natively (uses less memory) and has its own splitting
algorithm which is different than what OpenGL does. Perhaps it would
not be a bad thing to add an option to Mesh datablocks to disable that
smart render engine splitting and have it the same as the viewport,
and enable it by default even.
I don't know how important the smarter splitting it is in practice, in
Cycles I intentionally did not add it because it can pop in animation
and be inconsistent with the viewport, did not see complaints about it
so far.
Brecht.
On Wed, Nov 14, 2012 at 1:00 AM, CoDEmanX codem...@gmx.de wrote:
Alright, maybe what i had on mind isn't possible in your case.
As Blender has a tessface cache, I thought it should be used throughout
the application for everything that requires tessellated mesh geometry.
Polygon and tessface data can be accessed at the same time, so this is
basically non-destructive as well. What is missing IMO is a checkbox to
toggle display of tessfaces (we already see tesselated faces, but they
aren't outlined etc.)
A modifier might offer an extra ability of editing the triangulated mesh
non-destructively, not sure if possible, but if so, it would be great to
be able to adjust triangulation in certain spaces (tessfaces don't make
up nice triangles)
Am 14.11.2012 00:25, schrieb metalliandy:
The point of the modifier is not how it is triangulated, it is that the
triangulation is non destructive and can be visibly toggled on and off
by the user at will and without the need for undo steps :)
Also that quote you was from me, not Morten and I was 100% accurate.
Morten replied and said in his reply to me
This is not exactly the issue. Let me clarify.
The mikktspace part is done at quad level if there are quads and will
always give the same
tangent spaces at vertex level no matter what the order of vertices or
faces is.
This is its very strong advantage which other tangent space calculators
can't do.
After mikktspace has already run the problem occurs at a later stage
because before rendering/baking triangulation has to have been
performed.
So the issue is eventhough the tangent spaces at the vertices aren't
impacted by how quads are triangulated (since triangulation happens
later)
the interpolated tangent space is heavily impacted by which diagonal is
picked. Similar to how Gouraud shading is heavily impacted by which
diagonal is picked. So eventhough tangent space is consistent at the
vertices you get problems if baker and render don't pick the same
triangulation
due to differences in the interpolated tangent space.
I should mention I am using render triangulation loosely here since
it
can happen in a lot of places though for a game it would typically
happen
somewhere in the engine's tools pipeline. Anyway the advantage to this
modifier is it enforces a consistent triangulation which will be
received
by both baker and renderer (incl. Blender's renderer). Further, this is
achieved without causing permanent triangulation.
It's a sensible practice which is already used by artists in other
modeling
products.
Morten M.
I hope that clears everything up :)
-Andy
On 13/11/2012 23:12, CoDEmanX wrote:
Sounds to me like there is an inconsistency somewhere in Blender, which
causes the difference in mesh geometry between what baker uses and the
stored/exported data... Shouldn't everything in Blender use tessfaces,
if triangles are required?
When baking with an all quad mesh, the triangulation that is done
internally in Morten's TS might not match the manual triangulation that
the user applies on export [...] - Morten Mikkelsen
There shouldn't be manual triangulation, as export scripts can use
tessfaces to get triangulated geometry. Maybe here's the inconsistency?
The Triangulate Faces operator (former Quads to Tris) might create
triangles different from the tessfaces. I wonder how Morten's TS does
triangulation, hm, maybe I missed your point! (sorry if so)
Am 10.11.2012 19:32, schrieb Antony Riakiotakis:
Exactly, the point is not display, but data availability for baking. A
{0,1,2} {2,1,3} scheme is also being considered for the modifier.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers
Re: [Bf-committers] Triangulate modifier
When baking with an all quad mesh, the triangulation that is done internally in Morten's TS might not match the manual triangulation that the user applies on export, which potentially could cause issues because This is not exactly the issue. Let me clarify. The mikktspace part is done at quad level if there are quads and will always give the same tangent spaces at vertex level no matter what the order of vertices or faces is. This is its very strong advantage which other tangent space calculators can't do. After mikktspace has already run the problem occurs at a later stage because before rendering/baking triangulation has to have been performed. So the issue is eventhough the tangent spaces at the vertices aren't impacted by how quads are triangulated (since triangulation happens later) the interpolated tangent space is heavily impacted by which diagonal is picked. Similar to how Gouraud shading is heavily impacted by which diagonal is picked. So eventhough tangent space is consistent at the vertices you get problems if baker and render don't pick the same triangulation due to differences in the interpolated tangent space. I should mention I am using render triangulation loosely here since it can happen in a lot of places though for a game it would typically happen somewhere in the engine's tools pipeline. Anyway the advantage to this modifier is it enforces a consistent triangulation which will be received by both baker and renderer (incl. Blender's renderer). Further, this is achieved without causing permanent triangulation. It's a sensible practice which is already used by artists in other modeling products. Morten M. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [51258] trunk/blender: Cycles: Anisotropic BSDF enabled, with tangents now computed from the active UV map.
For aniso lighting computing tangents at vertex level is a total dead-end.
Not the way to go.
You want to compute the tangents at pixel level from the underlying
parametrization chosen.
It's the best way to significantly reduce the impact of the inherent
singularities which completely destroy the per vertex averaged tangent.
On Thu, Oct 11, 2012 at 4:43 AM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
It's working the same as blender internal currently, but I agree it
should be improved. This anisotropic BSDF node will get a tangent
input socket, and probably the geometry node should always output the
tangent from generated coordinates. I'm not sure yet where the tangent
from UV maps fits, if that should be its own node or maybe becomes
part of an existing one.
Brecht.
On Thu, Oct 11, 2012 at 2:10 AM, Daniel Salazar - 3Developer.com
zan...@gmail.com wrote:
This works really nice but I'm not sure about the implementation.
Making the assumption that if there's an UV that should be used to
generate tangents is no good. If I have UVs for a diffuse map how can
I make the aniso bsdf not use them for tangents but keep using the
default method? Also if I have multiple UV layers how can I pick the
one I want to be used as tangent source?
cheers
Daniel Salazar
patazstudio.com
On Wed, Oct 10, 2012 at 7:02 AM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
Revision: 51258
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=51258
Author: blendix
Date: 2012-10-10 13:02:20 + (Wed, 10 Oct 2012)
Log Message:
---
Cycles: Anisotropic BSDF enabled, with tangents now computed from the
active UV map.
It's using the Ward BSDF currently, which has some energy loss so might
be a bit
dark. More/better BSDF options can be implemented later.
Patch by Mike Farnsworth, some modifications by me. Currently it's not
possible yet
to set a custom tangent, that will follow as part of per-bsdf normals
patch.
Modified Paths:
--
trunk/blender/intern/cycles/blender/blender_mesh.cpp
trunk/blender/intern/cycles/blender/blender_shader.cpp
trunk/blender/intern/cycles/kernel/kernel_montecarlo.h
trunk/blender/intern/cycles/kernel/kernel_shader.h
trunk/blender/intern/cycles/kernel/kernel_types.h
trunk/blender/intern/cycles/kernel/svm/bsdf_ward.h
trunk/blender/intern/cycles/kernel/svm/svm.h
trunk/blender/intern/cycles/kernel/svm/svm_closure.h
trunk/blender/intern/cycles/kernel/svm/svm_geometry.h
trunk/blender/intern/cycles/kernel/svm/svm_types.h
trunk/blender/intern/cycles/render/attribute.cpp
trunk/blender/intern/cycles/render/graph.cpp
trunk/blender/intern/cycles/render/graph.h
trunk/blender/intern/cycles/render/nodes.cpp
trunk/blender/intern/cycles/render/nodes.h
trunk/blender/intern/cycles/util/util_types.h
trunk/blender/source/blender/blenkernel/intern/node.c
trunk/blender/source/blender/makesrna/intern/rna_nodetree_types.h
trunk/blender/source/blender/nodes/CMakeLists.txt
trunk/blender/source/blender/nodes/NOD_shader.h
trunk/blender/source/blender/nodes/shader/nodes/node_shader_bsdf_anisotropic.c
Modified: trunk/blender/intern/cycles/blender/blender_mesh.cpp
===
--- trunk/blender/intern/cycles/blender/blender_mesh.cpp
2012-10-10 12:54:36 UTC (rev 51257)
+++ trunk/blender/intern/cycles/blender/blender_mesh.cpp
2012-10-10 13:02:20 UTC (rev 51258)
@@ -33,6 +33,28 @@
/* Find/Add */
+static float3 tri_calc_tangent(float3 v0, float3 v1, float3 v2, float3
tx0, float3 tx1, float3 tx2)
+{
+ float3 duv1 = tx2 - tx0;
+ float3 duv2 = tx2 - tx1;
+ float3 dp1 = v2 - v0;
+ float3 dp2 = v2 - v1;
+ float det = duv1[0] * duv2[1] - duv1[1] * duv2[0];
+
+ if(det != 0.0f) {
+ return normalize(dp1 * duv2[1] - dp2 * duv1[1]);
+ }
+ else {
+ /* give back a sane default, using a valid edge as a
fallback */
+ float3 edge = v1 - v0;
+
+ if(len(edge) == 0.0f)
+ edge = v2 - v0;
+
+ return normalize(edge);
+ }
+}
+
static void create_mesh(Scene *scene, Mesh *mesh, BL::Mesh b_mesh,
const vectoruint used_shaders)
{
/* create vertices */
@@ -157,6 +179,67 @@
}
}
}
+
+ /* create texcoord-based tangent attributes */
+ {
+ BL::Mesh::tessface_uv_textures_iterator l;
+
+ for(b_mesh.tessface_uv_textures.begin(l); l !=
b_mesh.tessface_uv_textures.end(); ++l) {
+ AttributeStandard std = (l-active_render())?
ATTR_STD_TANGENT: ATTR_STD_NONE;
+
+
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [51258] trunk/blender: Cycles: Anisotropic BSDF enabled, with tangents now computed from the active UV map.
In case it's not clear. What I am saying is for actual uv unwraps use
mikktspace.
For a UV parametrization such as planar, cylindrical, spherical etc. use an
analytical
tangent evaluation at pixel level.
On Thu, Oct 11, 2012 at 12:44 PM, Morten Mikkelsen mikkels...@gmail.comwrote:
For aniso lighting computing tangents at vertex level is a total dead-end.
Not the way to go.
You want to compute the tangents at pixel level from the underlying
parametrization chosen.
It's the best way to significantly reduce the impact of the inherent
singularities which completely destroy the per vertex averaged tangent.
On Thu, Oct 11, 2012 at 4:43 AM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
It's working the same as blender internal currently, but I agree it
should be improved. This anisotropic BSDF node will get a tangent
input socket, and probably the geometry node should always output the
tangent from generated coordinates. I'm not sure yet where the tangent
from UV maps fits, if that should be its own node or maybe becomes
part of an existing one.
Brecht.
On Thu, Oct 11, 2012 at 2:10 AM, Daniel Salazar - 3Developer.com
zan...@gmail.com wrote:
This works really nice but I'm not sure about the implementation.
Making the assumption that if there's an UV that should be used to
generate tangents is no good. If I have UVs for a diffuse map how can
I make the aniso bsdf not use them for tangents but keep using the
default method? Also if I have multiple UV layers how can I pick the
one I want to be used as tangent source?
cheers
Daniel Salazar
patazstudio.com
On Wed, Oct 10, 2012 at 7:02 AM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
Revision: 51258
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=51258
Author: blendix
Date: 2012-10-10 13:02:20 + (Wed, 10 Oct 2012)
Log Message:
---
Cycles: Anisotropic BSDF enabled, with tangents now computed from the
active UV map.
It's using the Ward BSDF currently, which has some energy loss so
might be a bit
dark. More/better BSDF options can be implemented later.
Patch by Mike Farnsworth, some modifications by me. Currently it's not
possible yet
to set a custom tangent, that will follow as part of per-bsdf normals
patch.
Modified Paths:
--
trunk/blender/intern/cycles/blender/blender_mesh.cpp
trunk/blender/intern/cycles/blender/blender_shader.cpp
trunk/blender/intern/cycles/kernel/kernel_montecarlo.h
trunk/blender/intern/cycles/kernel/kernel_shader.h
trunk/blender/intern/cycles/kernel/kernel_types.h
trunk/blender/intern/cycles/kernel/svm/bsdf_ward.h
trunk/blender/intern/cycles/kernel/svm/svm.h
trunk/blender/intern/cycles/kernel/svm/svm_closure.h
trunk/blender/intern/cycles/kernel/svm/svm_geometry.h
trunk/blender/intern/cycles/kernel/svm/svm_types.h
trunk/blender/intern/cycles/render/attribute.cpp
trunk/blender/intern/cycles/render/graph.cpp
trunk/blender/intern/cycles/render/graph.h
trunk/blender/intern/cycles/render/nodes.cpp
trunk/blender/intern/cycles/render/nodes.h
trunk/blender/intern/cycles/util/util_types.h
trunk/blender/source/blender/blenkernel/intern/node.c
trunk/blender/source/blender/makesrna/intern/rna_nodetree_types.h
trunk/blender/source/blender/nodes/CMakeLists.txt
trunk/blender/source/blender/nodes/NOD_shader.h
trunk/blender/source/blender/nodes/shader/nodes/node_shader_bsdf_anisotropic.c
Modified: trunk/blender/intern/cycles/blender/blender_mesh.cpp
===
--- trunk/blender/intern/cycles/blender/blender_mesh.cpp
2012-10-10 12:54:36 UTC (rev 51257)
+++ trunk/blender/intern/cycles/blender/blender_mesh.cpp
2012-10-10 13:02:20 UTC (rev 51258)
@@ -33,6 +33,28 @@
/* Find/Add */
+static float3 tri_calc_tangent(float3 v0, float3 v1, float3 v2,
float3 tx0, float3 tx1, float3 tx2)
+{
+ float3 duv1 = tx2 - tx0;
+ float3 duv2 = tx2 - tx1;
+ float3 dp1 = v2 - v0;
+ float3 dp2 = v2 - v1;
+ float det = duv1[0] * duv2[1] - duv1[1] * duv2[0];
+
+ if(det != 0.0f) {
+ return normalize(dp1 * duv2[1] - dp2 * duv1[1]);
+ }
+ else {
+ /* give back a sane default, using a valid edge as a
fallback */
+ float3 edge = v1 - v0;
+
+ if(len(edge) == 0.0f)
+ edge = v2 - v0;
+
+ return normalize(edge);
+ }
+}
+
static void create_mesh(Scene *scene, Mesh *mesh, BL::Mesh b_mesh,
const vectoruint used_shaders)
{
/* create vertices */
@@ -157,6 +179,67 @@
}
}
}
+
+ /* create texcoord-based tangent attributes */
+ {
+ BL::Mesh
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [51258] trunk/blender: Cycles: Anisotropic BSDF enabled, with tangents now computed from the active UV map.
Ok, I can see we have an issue with singularities, but using mikktspace does not seem ideal for anisotropic shading. There's still many cases where you can line up the tangents quite well at UV seams even if the UV's are not connected, Generally this is not the case. It goes bad at least 95% or more of all cases where you try to just average tangents from an unwrap no matter what. Borders are splits when tangents aren't aligned so odds of this going well are close to non. results if you average with two neighboring triangles, but not the ones on the other side. That's not what happens though. What happens is that all the tangents surrounding the pole get added together. What you end up doing is stretching the highlight in a very distorted way across the entire top row of triangles. As I understand it mikktspace is based on comparing UV coordinates, whereas we should actually be deciding merge/nomerge based on the difference between tangents in UV space, with some threshold. If you were to try and achieve normal mapping using this approach then I can confidently tell you it's an awful solution. The idea has been tried and done to death by many of us game developers back in the day when the concepts of tangent space were still young. My recommendation is definitely that you use mikktspace for normal mapping. You use it for aniso as well if someone wants to use unwrap based tangents. And if someone wants to use orco then you synthesize the tangents. It's the only proper/stable/good way to do it. M.Fox. spend years on aniso in blender, studying various cases, and I am sure he can tell you first hand the per vertex averaged triangles just didn't work well. He was getting errors all the time. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [51258] trunk/blender: Cycles: Anisotropic BSDF enabled, with tangents now computed from the active UV map.
The problem is not the sphere. The problem is the general case which will almost never work well with per vertex averaged tangents in the context of aniso shading. The problem is of course that almost any case of a discontinuity will give offensive discontinuities in the lit results because it's anisotropic. You will consistently be presented with two choices 1 is to average and one is to split and you will be screwed whether you do or you don't. I promise you there is no way you can get this to behave well in the majority of cases. What will happen if you introduce a threshold is that some vertices will pop and some will split. If you follow a UV border down the seam at the surface of the mesh (something organic such as a human head) this will basically look horrendous. You'll see it switching, going from vertex to vertex, between awful distortions in the spec or hard discontinuities depending on whether or not it averaged or split. There will exist no global threshold that will give you a nice looking result. On Tue, Oct 16, 2012 at 11:56 AM, Brecht Van Lommel brechtvanlom...@pandora.be wrote: Right, for a sphere you need a singularity at the poles, but you do not need a seam between them too. Brecht On Tue, Oct 16, 2012 at 8:34 PM, Morten Mikkelsen mikkels...@gmail.com wrote: Ok, I'm still convinced we can do better than either, will try to figure it out. Can't blame a man for trying :) Food for thought though: http://en.wikipedia.org/wiki/Hairy_ball_theorem The hairy ball theorem! It basically says that a tangent field on the surface of a sphere in an odd dimensional vector space must partition somewhere. Couldn't help bring it up since it's a classic :) ___ 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] Collada importer/exporter kickout
Yes that's a very relevant point. A collada solution with just positions, UVs and normals is not a solution. In that case you might as well use obj format. I went through the hard work of writing a collada importer specifically to get skinning and animation into my tech frame-work. On Sat, Jan 7, 2012 at 5:03 AM, skoti skot...@o2.pl wrote: I know Collada importer / exporter is problematic (I wrote an importer for my engine and I know that everything in the Collada can be stored in N different ways). - If you want to use the model in Second Life / Google Earth, you have to use Collada, if you want to use models in engines WebGL/Flash3D practically have to use Collada (is there any web engine with FBX importer?), Most game engines use Collada for importing data (support for FBX a few). FBX exporter also has bugs. Well, that FBX is in a blender, but it is not usually an option for people using Collada. - If someone uses Collada it not for the base mesh + uv (then using *. obj) and for skeletal animation, lights, cameras and their animation (motion, color, light and their intensity), multiUV (uv for color, normalmap ... + uv for lightmap). And all this in current Collada exporter works well. - No other exporter does not work here as well as Collada - ofc has bugs, but it has nothing what could replace the Collada in this task. In the future, Alembic can replace Collada, but not for several years. IMO, better to leave Collada, until you will be able to replace it with success to other formats like Alembic (FBX is not popular in the software and you can not replace him Collada in most tasks). On 7 Jan, 2012, at 12:30, Ton Roosendaal wrote: Hi, I realize the proposal was harsh, but it was meant as a public statement as well (to khronos, opencollada team, etc). I don't want to blame it on the hard working devs here. We do have collada IO work at some level, and that has been proven useful in several cases. The job is just incredible hard to achieve. To move forward: - userts who successfully applied .dae could also check whether another exchange format would have done the job as good. Tried FBX? - note that for basic mesh (+uv) export, a quite simple script could do the job already. It is probably a few days job for a py scripter. - we are currently including about 100 MB of opencollada libs to make a feature work that's meant to be able to exchange (I+O) full shots or game environments, with character animation and so on. That's what Collada was designed for, and that's a target we can't support. -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 6 Jan, 2012, at 21:21, Morten Mikkelsen wrote: 1) Official announcement that Blender drops Collada support 2) Move Collada support into a branch, out of trunk 3) Create a tracker orphanage or branches or so, where we put all reports that are not in support (anymore). I just want to say though I am not up for the challenge of taking over on this sub project I would be sad to see Collada support taken out of trunk. I use it often also with skinning export. I know many users do and eventhough I understand everyone's frustration I prefer the implementation that is there now (which I use often) to no built-in version at all. I am not disagreeing with any of the frustrating aspects of Collada which you and others have mentioned. Just saying personally I do use it and would very much like to keep it in. With bugs and all :) I have seen many other commercial tools with awful crappy .3ds importers and exporters but bad as they were they didn't take them out because people were still relying on them and using them. Despite the bugs in them. Cheers, Morten. ___ 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] Collada importer/exporter kickout
In my case I do not need morphs. I do need animation and skinning though. And obviously also geometries and materials. And it sounds like you have this covered? I have no sense of loyalty toward OpenCollada so if this is a viable solution I am for it. Can you make it available somewhere with instructions on how to install it so people can test it? Cheers and thanks, Morten On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietsky redu...@gmail.com wrote: Hi guys, I made my own Collada exporter in Python and that's what I've been using. It's less than 1k lines of code and does not depend upon any library or anything, but it exports everything except morphs. I don't have much time to work on it at the moment, but it's so simple and complete that if anyone else want's to work on it, it should be really easy. I'm also not an expert at Python or Blender API so someone more experience can probably shape it up better. It's also much more stable than the official one (due to it being so small). Feel free to do anything with it or integrate it into Blender, just credit me on the file. I would love to work more on it, or even make a proper importer since I have a high level of expertise in Collada, but I have very little time and must work to earn my meals. Cheers! Juan Linietsky On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsen mikkels...@gmail.com wrote: Yes that's a very relevant point. A collada solution with just positions, UVs and normals is not a solution. In that case you might as well use obj format. I went through the hard work of writing a collada importer specifically to get skinning and animation into my tech frame-work. On Sat, Jan 7, 2012 at 5:03 AM, skoti skot...@o2.pl wrote: I know Collada importer / exporter is problematic (I wrote an importer for my engine and I know that everything in the Collada can be stored in N different ways). - If you want to use the model in Second Life / Google Earth, you have to use Collada, if you want to use models in engines WebGL/Flash3D practically have to use Collada (is there any web engine with FBX importer?), Most game engines use Collada for importing data (support for FBX a few). FBX exporter also has bugs. Well, that FBX is in a blender, but it is not usually an option for people using Collada. - If someone uses Collada it not for the base mesh + uv (then using *. obj) and for skeletal animation, lights, cameras and their animation (motion, color, light and their intensity), multiUV (uv for color, normalmap ... + uv for lightmap). And all this in current Collada exporter works well. - No other exporter does not work here as well as Collada - ofc has bugs, but it has nothing what could replace the Collada in this task. In the future, Alembic can replace Collada, but not for several years. IMO, better to leave Collada, until you will be able to replace it with success to other formats like Alembic (FBX is not popular in the software and you can not replace him Collada in most tasks). On 7 Jan, 2012, at 12:30, Ton Roosendaal wrote: Hi, I realize the proposal was harsh, but it was meant as a public statement as well (to khronos, opencollada team, etc). I don't want to blame it on the hard working devs here. We do have collada IO work at some level, and that has been proven useful in several cases. The job is just incredible hard to achieve. To move forward: - userts who successfully applied .dae could also check whether another exchange format would have done the job as good. Tried FBX? - note that for basic mesh (+uv) export, a quite simple script could do the job already. It is probably a few days job for a py scripter. - we are currently including about 100 MB of opencollada libs to make a feature work that's meant to be able to exchange (I+O) full shots or game environments, with character animation and so on. That's what Collada was designed for, and that's a target we can't support. -Ton- Ton Roosendaal Blender Foundation t...@blender.org www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 6 Jan, 2012, at 21:21, Morten Mikkelsen wrote: 1) Official announcement that Blender drops Collada support 2) Move Collada support into a branch, out of trunk 3) Create a tracker orphanage or branches or so, where we put all reports that are not in support (anymore). I just want to say though I am not up for the challenge of taking over on this sub project I would be sad to see Collada support taken out of trunk. I use it often also with skinning export. I know many users do and eventhough I understand everyone's frustration I prefer the implementation
Re: [Bf-committers] Collada importer/exporter kickout
As an example of people having problems with its complexity OpenCollada doesn't drain collada sources correctly at all. They make many assumptions such as data being non interleaved. On Sat, Jan 7, 2012 at 8:23 AM, Juan Linietsky redu...@gmail.com wrote: On Fri, Jan 6, 2012 at 9:04 PM, Francesco Zoffoli maker...@gmail.com wrote: I'm just curious: why can't an external library be used? I think the biggest problem with Collada is that the specification seems like something huge and complex, so most people resorts to a library, which in turn ends up in something even more bigger and complex with several layers of complexiity that is a nightmare to maintain. In reality, Collada is a very simple format that is very easy to parse, but it definitely takes some work to really grasp and understand all of it, because it's very flexible (way too much more than needed I think). I also wish it was more mantained and better documented at this point, too because most official examples are either broken or incompatible with the specification. Cheers Juan Linietsky ___ 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] Collada importer/exporter kickout
Erwin I consider this irrelevant in the current discussion. Programmers should they choose to can write .blend importers but the current discussion is what to do about collada for blender. Telling everyone to write .blend importers (incl artists) is not a viable alternative. That being said it sounds like Juan has a good start here. On Sat, Jan 7, 2012 at 9:23 AM, Erwin Coumans erwin.coum...@gmail.comwrote: You are right that in some cases an exporter is better, but in many cases a C/C++ .blend importer is a better to go. I just wanted to remind anyone reading this thread that there is an easy way to extract any data from Blender in C++, including animation curves, skinning info, textures etc, without the issues of COLLADA and FBX. I'm not familiar with baking, but you might be able to store the baked data in the .blend file. Thanks, Erwin On 7 January 2012 09:10, Juan Linietsky redu...@gmail.com wrote: Erwin, That looks awesome and really useful, however the main advantage of an importer is the ability to bake everything (IK and other constraints) just like it's displayed in Blender. Cheers Juan Linietsky On Sat, Jan 7, 2012 at 2:07 PM, Erwin Coumans erwin.coum...@gmail.com wrote: Instead of going through the COLLADA or other intermediate format you can directly extract any data from a .blend using this C++ .blend parser: http://tinyurl.com/6s7k9zw AnimKit with the .blend loader includes a small sample that loads a .blend file, extracts textures, meshes, animations, skinning and physics info. It shows a skinned skeletal animated character using AnimKit and GLUT (keeping dependencies to a minimum) Cheers, Erwin On 7 January 2012 07:38, Morten Mikkelsen mikkels...@gmail.com wrote: In my case I do not need morphs. I do need animation and skinning though. And obviously also geometries and materials. And it sounds like you have this covered? I have no sense of loyalty toward OpenCollada so if this is a viable solution I am for it. Can you make it available somewhere with instructions on how to install it so people can test it? Cheers and thanks, Morten On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietsky redu...@gmail.com wrote: Hi guys, I made my own Collada exporter in Python and that's what I've been using. It's less than 1k lines of code and does not depend upon any library or anything, but it exports everything except morphs. I don't have much time to work on it at the moment, but it's so simple and complete that if anyone else want's to work on it, it should be really easy. I'm also not an expert at Python or Blender API so someone more experience can probably shape it up better. It's also much more stable than the official one (due to it being so small). Feel free to do anything with it or integrate it into Blender, just credit me on the file. I would love to work more on it, or even make a proper importer since I have a high level of expertise in Collada, but I have very little time and must work to earn my meals. Cheers! Juan Linietsky On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsen mikkels...@gmail.com wrote: Yes that's a very relevant point. A collada solution with just positions, UVs and normals is not a solution. In that case you might as well use obj format. I went through the hard work of writing a collada importer specifically to get skinning and animation into my tech frame-work. On Sat, Jan 7, 2012 at 5:03 AM, skoti skot...@o2.pl wrote: I know Collada importer / exporter is problematic (I wrote an importer for my engine and I know that everything in the Collada can be stored in N different ways). - If you want to use the model in Second Life / Google Earth, you have to use Collada, if you want to use models in engines WebGL/Flash3D practically have to use Collada (is there any web engine with FBX importer?), Most game engines use Collada for importing data (support for FBX a few). FBX exporter also has bugs. Well, that FBX is in a blender, but it is not usually an option for people using Collada. - If someone uses Collada it not for the base mesh + uv (then using *. obj) and for skeletal animation, lights, cameras and their animation (motion, color, light and their intensity), multiUV (uv for color, normalmap ... + uv for lightmap). And all this in current Collada exporter works well. - No other exporter does not work here as well as Collada - ofc has bugs, but it has nothing what could replace the Collada
Re: [Bf-committers] Collada importer/exporter kickout
I acknowledge that the amount of work you guys have put into OpenCollada is significant and I am definitely pleased with this as an option. That being said I am beginning to warm up to what sergei is suggesting more and I am actually a collada user myself. Correct me if I am wrong but the way it works for autodesk these products by default ship with some crappy collada exporter that someone within the castle of autodesk has authored. Then as an alternative option you guys made OpenCollada plugins available for Maya and 3dsmax from your website correct? So when you think about it is there really any harm in Blender shipping with a crappy collada exporter of its own, like autodesk, and then having the option of downloading an OpenCollada blugin for Blender from an off-site location as well (Possibly even your site)? And Juan no offense intended here I am just making a comparison. I am not saying your code is literally crappy! Cheers, Morten. On Sat, Jan 7, 2012 at 1:22 PM, Sebastian sebast...@opencollada.org wrote: Erwin already announced it: I've contributed the code generation libraries under the MIT license and committed it to our Subversion repository. You should see this as our commitment to the future of OpenCOLLADA. OpenCOLLADA is and was a lot of work, it's far away from being perfect or even error free but I would not suggest to develop yet another DAE importer/exporter specifically for Blender or even drop support for it. For the COLLADA community Blender is definitely one of the most important stakeholders to stop supporting COLLADA would make things in DCC exchange even worse. We are currently discussing further financing of OpenCOLLADA and will spend more time the next months on bugfixing and conformance tests. Sebastian ___ 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] Collada importer/exporter kickout
Okay I guess you did misunderstand my misuse of the word crappy. What I meant was more like less likely to work with existing OpenCollada importers. Those which are already used in other apps. Clearly an OpenCollada exporter is more likely to work with an OpenCollada importer across apps. This was all I meant really. And implicitly this was also what Sebastian was saying in regards to the dangers of introducing yet another one. It's really a reflection of the Collada format being ridiculously broad. I am not calling anyone's code literally crap so sorry I misused this work. On Sat, Jan 7, 2012 at 3:24 PM, Juan Linietsky redu...@gmail.com wrote: And Juan no offense intended here I am just making a comparison. I am not saying your code is literally crappy! The word crappy is completely subjective. In this case, what matters is: 1) Whether something works or not. It may have bugs and need a little more work in the export options area, but it definitely does work (or is very close). 2) How easy it is to maintain. I think we can agree that a ~1k loc python codebase is much easier to maintain than a huge library and wrapper code. Cheers Juan ___ 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] collada
I agree Marty. It's awesome. Give my best to the doc! :) On Sat, Jan 7, 2012 at 2:29 PM, Michael Fox mfoxd...@gmail.com wrote: On 08/01/12 08:28, angjmi...@gulftel.com wrote: hey i am hearing that your planning on removing collada!! i know there is a lot of issues with it but, at-least as it is right now it can be made to work. a lot of people depend on this as their intermediate file format, now i know no one likes the idea of what i am doing (cryblend) but someone had to, sorry to go a bit off here, but why would no one like what you have done with cryblend, i think its absolutely awesome what you have done (even posted about it on G+) ___ 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] Collada importer/exporter kickout
1) Official announcement that Blender drops Collada support 2) Move Collada support into a branch, out of trunk 3) Create a tracker orphanage or branches or so, where we put all reports that are not in support (anymore). I just want to say though I am not up for the challenge of taking over on this sub project I would be sad to see Collada support taken out of trunk. I use it often also with skinning export. I know many users do and eventhough I understand everyone's frustration I prefer the implementation that is there now (which I use often) to no built-in version at all. I am not disagreeing with any of the frustrating aspects of Collada which you and others have mentioned. Just saying personally I do use it and would very much like to keep it in. With bugs and all :) I have seen many other commercial tools with awful crappy .3ds importers and exporters but bad as they were they didn't take them out because people were still relying on them and using them. Despite the bugs in them. Cheers, Morten. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collada importer/exporter kickout
I agree, I could also live with ditching the importer if it meant keeping the exporter. But either way I'll take current collada version to no collada version at all. On Fri, Jan 6, 2012 at 5:11 PM, skoti skot...@o2.pl wrote: Assimp only importer (exporter in blender is the most important), and even in assimp Collada importer is weak. Blender use external library for Collada (OpenCollada libs). Collada format is an important and IMO it should not be removed. Collada is used in many game engine, engine Web3D (WebGL or flash engine), and everywhere, where we exchange information. It seems to me that it is better to leave the exporter in the trunk than reduce the functionality of the program (for many it becomes useless - now an exporter / importer, blender works well with programs based on OpenCollada / FCollada / Collada DOM - works better than autodesk exporter (creates files Collada-like )). I'm just curious: why can't an external library be used? I know about Assimp, i double checked and it seams that it supports collada import/export(at least they say so on their site, and i think it is full support since it isn't marked with an * [2][3]). It also has a C or C++ API. The licence is (a kind of [4])BSD, is this a problem? This would offload main devs from format support. In addition blender would be able to import/export all the format the external library already handles. And in case specific files must be supported, this can be archived with python or a specific imp/exporter. Is there a reason why blender shouldn't rely on an existing library, or it's a licence/features problem with the existing ones? [1] http://assimp.sourceforge.net/index.html [2] http://assimp.sourceforge.net/main_features_formats.html [3] http://assimp.sourceforge.net/main_features_export.html [4] http://assimp.sourceforge.net/main_license.html ___ 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] Blender tangent space calculation
I am not 100% sure I understand you correctly but your fix doesn't sound correct but perhaps I am misunderstanding you. Anyway, the welder is going to generate a zero based index list unlike what is used within Blender. If you want to use the indexed result within a Blender context you'd have to put a dummy vertex at the beginning of the vertex array such that all other vertices are offset by one entry and then you'd add all the welder-generated indices by +1 to offset to after the dummy vertex. This way triangles can still have their fourth index as 0 which points to the dummy vertex and within Blender means no vertex assigned. On Sat, Nov 19, 2011 at 9:27 AM, Eugene Minov minov@gmail.com wrote: Correct, this is how blender does it everywhere in its code-base. Ok. I've asked because after weldind I've gotten this problem with some quads. But today seems that I solve it by swapping the first vertex in the vert array with the first finded vertex that is not indexed to any of the 4'th face's index. On Sat, Nov 19, 2011 at 1:13 AM, Morten Mikkelsen mikkels...@gmail.com wrote: I wanted to ask about this line: const int iGetNrVerts= data-mface[face_num].v4!=0 ? 4 : 3; Or there is no way that last index points to zero? Correct, this is how blender does it everywhere in its code-base. Super glad to hear you're getting useful results! Be sure to submit a patch for review. ___ 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] Blender tangent space calculation
If you want to use the indexed result within a Blender context you'd have to put a dummy vertex at the beginning of the vertex array such that all other vertices are offset by one entry I mean put a dummy vertex in front of the unique vertices of course (meaning after welding). And also +1 to the indices you get after welding. On Sat, Nov 19, 2011 at 12:35 PM, Morten Mikkelsen mikkels...@gmail.comwrote: I am not 100% sure I understand you correctly but your fix doesn't sound correct but perhaps I am misunderstanding you. Anyway, the welder is going to generate a zero based index list unlike what is used within Blender. If you want to use the indexed result within a Blender context you'd have to put a dummy vertex at the beginning of the vertex array such that all other vertices are offset by one entry and then you'd add all the welder-generated indices by +1 to offset to after the dummy vertex. This way triangles can still have their fourth index as 0 which points to the dummy vertex and within Blender means no vertex assigned. On Sat, Nov 19, 2011 at 9:27 AM, Eugene Minov minov@gmail.com wrote: Correct, this is how blender does it everywhere in its code-base. Ok. I've asked because after weldind I've gotten this problem with some quads. But today seems that I solve it by swapping the first vertex in the vert array with the first finded vertex that is not indexed to any of the 4'th face's index. On Sat, Nov 19, 2011 at 1:13 AM, Morten Mikkelsen mikkels...@gmail.com wrote: I wanted to ask about this line: const int iGetNrVerts= data-mface[face_num].v4!=0 ? 4 : 3; Or there is no way that last index points to zero? Correct, this is how blender does it everywhere in its code-base. Super glad to hear you're getting useful results! Be sure to submit a patch for review. ___ 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] Blender tangent space calculation
I wanted to ask about this line: const int iGetNrVerts= data-mface[face_num].v4!=0 ? 4 : 3; Or there is no way that last index points to zero? Correct, this is how blender does it everywhere in its code-base. Super glad to hear you're getting useful results! Be sure to submit a patch for review. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender tangent space calculation
Don't forget to look in do_multires_bake() in object_bake.c It shows you how to add the tangent layer: float *pvtangent= NULL; // create tangent vectors if not already created if(CustomData_get_layer_index(dm-faceData, CD_TANGENT) == -1) DM_add_tangent_layer(dm); // get pointer to the already generated tangents pvtangent= DM_get_face_data_layer(dm, CD_TANGENT); On Thu, Nov 17, 2011 at 8:49 AM, Eugene Minov minov@gmail.com wrote: The proper way to get the tangent layer can be seen in: https://svn.blender.org/svnroot/bf-blender/trunk/blender/source/blender/editors/object/object_bake.c Okay, I've found a 'multiresbake_get_normal' function for correct normals calculation. I also looked into 'DM_add_tangent_layer' function in: https://svn.blender.org/svnroot/bf-blender/trunk/blender/source/blender/blenkernel/intern/DerivedMesh.c According to it, the tangent layer is filling by tangents when created. So I do need only to access and welding them and normals? That's good if so. Today I had time to try understand how RNA's works. And I almost create and test python interface with collections for faces and indexed vertices with normals and tangents in it. Hopefully soon I'll start welding. If you need a free ultra simple welder there's one here -- http://jbit.net/~sparky/academic/welder/ You specify how many floats you have per vertex and it will weld for you. Okay, good one, I think I'll use it :) Thanks! On Wed, Nov 16, 2011 at 8:43 PM, Morten Mikkelsen mikkels...@gmail.com wrote: Sorry for confusing you here but I think I found a better reference for you since you'll be needing the tangents too and you are not supposed to be building them yourself. The proper way to get the tangent layer can be seen in: https://svn.blender.org/svnroot/bf-blender/trunk/blender/source/blender/editors/object/object_bake.c do_multires_bake() These are being fetched after the line: float *pvtangent= NULL; These are then read in the function flush_pixel() including the normal which is fetched from there using multiresbake_get_normal() which as you can see looks a lot like the GetNormal() function I pointed you to in DerivedMesh.c. Anyway, definitely use this file as your reference. I should have shown you this one from the beginning. If you need a free ultra simple welder there's one here -- http://jbit.net/~sparky/academic/welder/ You specify how many floats you have per vertex and it will weld for you. On Wed, Nov 16, 2011 at 5:32 AM, Eugene Minov minov@gmail.com wrote: If you can get hold of the dm (DerivedMesh) on the c side of things then I can show you how to get the correct normals and tangents and even help you get them welded should you want this. Ok! Sounds good to me :) So right now I in progress of checkout latest svn sources and compile blender. (had problems with net) Then first of I'll try to create test version of python/C interface. I've not decided yet what names I'll use for it. And finally will be trying to implement it looking in DerivedMesh.c, I think that it's realy are a good example. If or when I have a problem, I'll be glad to use your help :) Many thanks for your kind cooperation! On Tue, Nov 15, 2011 at 10:41 PM, Morten Mikkelsen mikkels...@gmail.com wrote: I don't know anything about Python but if you can get hold of the dm (DerivedMesh) on the c side of things then I can show you how to get the correct normals and tangents and even help you get them welded should you want this. On Tue, Nov 15, 2011 at 10:43 AM, Eugene Minov minov@gmail.com wrote: Yes, I absolutely agree, hard faces obviously must be exported in the same way how they seen in render. I think they can welds along with tangents. On Tue, Nov 15, 2011 at 9:01 PM, Morten Mikkelsen mikkels...@gmail.com wrote: There is no point in doing this unless you export the correct tangents and normals. That is the ones that were used to bake the normal map. I realize it blows that there is no API function to get the render normal. So what you have to do is produce it yourself like is done in DerivedMesh.c https://svn.blender.org/svnroot/bf-blender/trunk/blender/source/blender/blenkernel/intern/DerivedMesh.c and many other places as well. An example in this file is the static function GetNormal() which is used as a call-back function by mikktspace.c and you can see how it uses the averaged normal if the face is set to smooth and it uses the face normal which it calculates itself if the face is set to flat. If you are going to make an api to export tangents I for one cannot
Re: [Bf-committers] Blender tangent space calculation
And flush_pixel() shows you how to traverse the buffer. Essentially the way it works in blender is there's always 4 of them per face whether it's a triangle or a quad. On Thu, Nov 17, 2011 at 9:31 AM, Morten Mikkelsen mikkels...@gmail.comwrote: Don't forget to look in do_multires_bake() in object_bake.c It shows you how to add the tangent layer: float *pvtangent= NULL; // create tangent vectors if not already created if(CustomData_get_layer_index(dm-faceData, CD_TANGENT) == -1) DM_add_tangent_layer(dm); // get pointer to the already generated tangents pvtangent= DM_get_face_data_layer(dm, CD_TANGENT); On Thu, Nov 17, 2011 at 8:49 AM, Eugene Minov minov@gmail.com wrote: The proper way to get the tangent layer can be seen in: https://svn.blender.org/svnroot/bf-blender/trunk/blender/source/blender/editors/object/object_bake.c Okay, I've found a 'multiresbake_get_normal' function for correct normals calculation. I also looked into 'DM_add_tangent_layer' function in: https://svn.blender.org/svnroot/bf-blender/trunk/blender/source/blender/blenkernel/intern/DerivedMesh.c According to it, the tangent layer is filling by tangents when created. So I do need only to access and welding them and normals? That's good if so. Today I had time to try understand how RNA's works. And I almost create and test python interface with collections for faces and indexed vertices with normals and tangents in it. Hopefully soon I'll start welding. If you need a free ultra simple welder there's one here -- http://jbit.net/~sparky/academic/welder/ You specify how many floats you have per vertex and it will weld for you. Okay, good one, I think I'll use it :) Thanks! On Wed, Nov 16, 2011 at 8:43 PM, Morten Mikkelsen mikkels...@gmail.com wrote: Sorry for confusing you here but I think I found a better reference for you since you'll be needing the tangents too and you are not supposed to be building them yourself. The proper way to get the tangent layer can be seen in: https://svn.blender.org/svnroot/bf-blender/trunk/blender/source/blender/editors/object/object_bake.c do_multires_bake() These are being fetched after the line: float *pvtangent= NULL; These are then read in the function flush_pixel() including the normal which is fetched from there using multiresbake_get_normal() which as you can see looks a lot like the GetNormal() function I pointed you to in DerivedMesh.c. Anyway, definitely use this file as your reference. I should have shown you this one from the beginning. If you need a free ultra simple welder there's one here -- http://jbit.net/~sparky/academic/welder/ You specify how many floats you have per vertex and it will weld for you. On Wed, Nov 16, 2011 at 5:32 AM, Eugene Minov minov@gmail.com wrote: If you can get hold of the dm (DerivedMesh) on the c side of things then I can show you how to get the correct normals and tangents and even help you get them welded should you want this. Ok! Sounds good to me :) So right now I in progress of checkout latest svn sources and compile blender. (had problems with net) Then first of I'll try to create test version of python/C interface. I've not decided yet what names I'll use for it. And finally will be trying to implement it looking in DerivedMesh.c, I think that it's realy are a good example. If or when I have a problem, I'll be glad to use your help :) Many thanks for your kind cooperation! On Tue, Nov 15, 2011 at 10:41 PM, Morten Mikkelsen mikkels...@gmail.com wrote: I don't know anything about Python but if you can get hold of the dm (DerivedMesh) on the c side of things then I can show you how to get the correct normals and tangents and even help you get them welded should you want this. On Tue, Nov 15, 2011 at 10:43 AM, Eugene Minov minov@gmail.com wrote: Yes, I absolutely agree, hard faces obviously must be exported in the same way how they seen in render. I think they can welds along with tangents. On Tue, Nov 15, 2011 at 9:01 PM, Morten Mikkelsen mikkels...@gmail.com wrote: There is no point in doing this unless you export the correct tangents and normals. That is the ones that were used to bake the normal map. I realize it blows that there is no API function to get the render normal. So what you have to do is produce it yourself like is done in DerivedMesh.c https://svn.blender.org/svnroot/bf-blender/trunk/blender/source/blender/blenkernel/intern/DerivedMesh.c and many other places as well. An example in this file is the static function GetNormal() which is used as a call-back function by mikktspace.c
Re: [Bf-committers] Blender tangent space calculation
Sorry for confusing you here but I think I found a better reference for you since you'll be needing the tangents too and you are not supposed to be building them yourself. The proper way to get the tangent layer can be seen in: https://svn.blender.org/svnroot/bf-blender/trunk/blender/source/blender/editors/object/object_bake.c do_multires_bake() These are being fetched after the line: float *pvtangent= NULL; These are then read in the function flush_pixel() including the normal which is fetched from there using multiresbake_get_normal() which as you can see looks a lot like the GetNormal() function I pointed you to in DerivedMesh.c. Anyway, definitely use this file as your reference. I should have shown you this one from the beginning. If you need a free ultra simple welder there's one here -- http://jbit.net/~sparky/academic/welder/ You specify how many floats you have per vertex and it will weld for you. On Wed, Nov 16, 2011 at 5:32 AM, Eugene Minov minov@gmail.com wrote: If you can get hold of the dm (DerivedMesh) on the c side of things then I can show you how to get the correct normals and tangents and even help you get them welded should you want this. Ok! Sounds good to me :) So right now I in progress of checkout latest svn sources and compile blender. (had problems with net) Then first of I'll try to create test version of python/C interface. I've not decided yet what names I'll use for it. And finally will be trying to implement it looking in DerivedMesh.c, I think that it's realy are a good example. If or when I have a problem, I'll be glad to use your help :) Many thanks for your kind cooperation! On Tue, Nov 15, 2011 at 10:41 PM, Morten Mikkelsen mikkels...@gmail.com wrote: I don't know anything about Python but if you can get hold of the dm (DerivedMesh) on the c side of things then I can show you how to get the correct normals and tangents and even help you get them welded should you want this. On Tue, Nov 15, 2011 at 10:43 AM, Eugene Minov minov@gmail.com wrote: Yes, I absolutely agree, hard faces obviously must be exported in the same way how they seen in render. I think they can welds along with tangents. On Tue, Nov 15, 2011 at 9:01 PM, Morten Mikkelsen mikkels...@gmail.com wrote: There is no point in doing this unless you export the correct tangents and normals. That is the ones that were used to bake the normal map. I realize it blows that there is no API function to get the render normal. So what you have to do is produce it yourself like is done in DerivedMesh.c https://svn.blender.org/svnroot/bf-blender/trunk/blender/source/blender/blenkernel/intern/DerivedMesh.c and many other places as well. An example in this file is the static function GetNormal() which is used as a call-back function by mikktspace.c and you can see how it uses the averaged normal if the face is set to smooth and it uses the face normal which it calculates itself if the face is set to flat. If you are going to make an api to export tangents I for one cannot emphasize enough that I prefer an all or nothing solution. Either do it right or don't do it at all. The last thing we need is to introduce a new tangent space standard within blender. Either export the correct basis that was used for baking (this includes the normal) or don't try to do it at all. ___ 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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender tangent space calculation
There is no point in doing this unless you export the correct tangents and normals. That is the ones that were used to bake the normal map. I realize it blows that there is no API function to get the render normal. So what you have to do is produce it yourself like is done in DerivedMesh.chttps://svn.blender.org/svnroot/bf-blender/trunk/blender/source/blender/blenkernel/intern/DerivedMesh.c and many other places as well. An example in this file is the static function GetNormal() which is used as a call-back function by mikktspace.c and you can see how it uses the averaged normal if the face is set to smooth and it uses the face normal which it calculates itself if the face is set to flat. If you are going to make an api to export tangents I for one cannot emphasize enough that I prefer an all or nothing solution. Either do it right or don't do it at all. The last thing we need is to introduce a new tangent space standard within blender. Either export the correct basis that was used for baking (this includes the normal) or don't try to do it at all. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender tangent space calculation
I don't know anything about Python but if you can get hold of the dm (DerivedMesh) on the c side of things then I can show you how to get the correct normals and tangents and even help you get them welded should you want this. On Tue, Nov 15, 2011 at 10:43 AM, Eugene Minov minov@gmail.com wrote: Yes, I absolutely agree, hard faces obviously must be exported in the same way how they seen in render. I think they can welds along with tangents. On Tue, Nov 15, 2011 at 9:01 PM, Morten Mikkelsen mikkels...@gmail.com wrote: There is no point in doing this unless you export the correct tangents and normals. That is the ones that were used to bake the normal map. I realize it blows that there is no API function to get the render normal. So what you have to do is produce it yourself like is done in DerivedMesh.c https://svn.blender.org/svnroot/bf-blender/trunk/blender/source/blender/blenkernel/intern/DerivedMesh.c and many other places as well. An example in this file is the static function GetNormal() which is used as a call-back function by mikktspace.c and you can see how it uses the averaged normal if the face is set to smooth and it uses the face normal which it calculates itself if the face is set to flat. If you are going to make an api to export tangents I for one cannot emphasize enough that I prefer an all or nothing solution. Either do it right or don't do it at all. The last thing we need is to introduce a new tangent space standard within blender. Either export the correct basis that was used for baking (this includes the normal) or don't try to do it at all. ___ 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] Blender tangent space calculation
So why not to simply adding possibility for generate/access a tangent normals into the python api? If it's not already available in the python API then I agree that it's a good idea. However, you'd need to supply support for normals as well since at this point the python API only gives access to the unconditionally averaged/smooth normals at the vertices. Ie. the api doesn't take faces set to soft/hard into account when submitting normals back to the script. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender tangent space calculation
There you go buddy -- http://lmgtfy.com/?q=blender+tangent+space
On Sun, Nov 13, 2011 at 8:46 AM, Eugene Minov minov@gmail.com wrote:
Hi.
I am sorry if I subscribe into a wrong place, I am new and I've not
actually planned to change or to debug the blender sources yet.
But I trying to write app that'll be render models with normal mapping
exported from blender, and I have a question about how exactly is blender
calculates a tangent vectors when Unwrap operation in the editing mode
performs?
Calculating tangents in my app in usual manner (using UV coords and verts
positions) gives me different tangents for each face of the same vertex
indexed from, and thus crumpled normal map looking.
Then by looking into blender sources (searching by 'tangent' keyword) I've
found a couple of functions with tangents calculations, like:
float axis[3] = {0.0f, 0.0f, 1.0f};
cross_v3_v3v3(tangent, normal, up);
normalize_v3(tangent);
After I tried same method in my program I've gotten almost perfect looking
model, depending on what initial axis I've used.
To choose, which axis to use (0, 0, 1), (0, 1, 0) or (1, 0, 0) for each
normal, I calculate max dot product of tangent calculated by each axis with
tangent calculated from UV coords.
But still it seems that in some rare vertices tangent is calculates wrong,
maybe because of wrong initial axis.
So, can anyone please give me any information about tangents calculation
formula that blender uses while generates UV coords or some advice about
choosing initial axis.
Thanks for help.
Eugene
___
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] Bicubic filtering for bump maps, patch + discussion
It should be mentioned that two variants are 3) are possible. One is to simply convert the color image to grayscale during uploads to the gpu. The other is to actually support single channel image painting in blender and then only support the bicubic for such bump maps. Though I would be thrilled to see single channel images supported in blender for painting I actually still like the idea of converting the bump map during upload to grayscale because it makes it more efficient all around whether bicubic is in use or not. It consumes less memory and makes it more feasible for people to use the new (2.61) 16 bits per height in glsl when the bump map is a float image. However, I have no idea if this is possible or not since it requires knowing at that point in the code that the texture to be uploaded is used by a material with bump and it also requires knowledge on whether or not the same texture will be used for anything color related. Another option is of course to define it such that blender always does bump using red channel only but I am guessing I won't win any popularity contests with this suggestion? :) Anyway, the difference in quality is very significant so I'm hoping we can work this in somehow. Several artists were bugged by the lack of quality during close-up when painting bump maps. 2011/10/26 Αντώνης Ρυακιωτάκης kal...@gmail.com Hi everyone, there has been some work by Morten Mikkelsen for supporting bicubic filtering for bump maps. I have helped adapting the code to glsl and the result can be seen here: old: http://www.pasteall.org/pic/19660 new: http://www.pasteall.org/pic/19659 The patch is here: http://www.pasteall.org/25833/diff Notes: This patch substitutes the Best Quality setting on capable GPUs with bicubic filtering. It may be preferable to make an extra setting altogether for this? The functionality relies on GLSL 1.3 and uses the textureGather function to quickly get samples from nearby texels. Getting the samples normally would require 16 instead of 4 texture samples. However only the red component is taken. This implies that for correct behaviour the rgb scannels need to be identical. Bump maps are usually monochrome anyway but it is possible to use a colour image as a bump map with in trunk functionality. After some discussion with Morten we thought that there are some ways this could be done(with increasing difficulty IMO): 1) Leave it up to the artist to enforce that he uses only black/white images 2) Use 16 samples and make this an extra setting for good systems 3) Make 1-channel images and a luminance upload path for 1-channel images. Best Quality bump maps only work with one-channel images Thoughts? ___ 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] image-save + .blend save destroys work without warning!
I've found that most blender users incl. advanced ones generally don't know this about blender so I think it needs to be discussed. Let me first explain how this works. What happens is that when you save out an image to file and then subsequently save your .blend and then reload your .blend then the image buffer will be reloaded from the image you saved. As an example let's say you went through the hard work of hand painting a floating point image and then save out, in Blender, as png, tga or even tiff (which is setup to 8 bits). If you then save the .blend file (and reload) then all your precision is lost and cannot be recovered. No warning is given and no options are presented when saving out an image. A similar example is alpha. Most of the image formats support alpha but for whatever reason Blender does not save alpha with all of them. If you pick such a format, save, then save the .blend and finally reload .blend then the alpha will be lost. I was hoping to have a discussion here on committers and hear what you all think is a good solution. I can personally understand why blender chooses to reload images from file since saving the image buffers with .blend file directly (to preserve them) is just asking for an explosion in file size. But in my opinion there should be a warning when there will be loss of data associated with a save (when its not just straight pass-through). Also I would prefer that when you do save out that you should be presented with options available for the chosen file format such as bit depths and number of channels or something. Cheers, Morten Mikkelsen ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New BF team member: Sergey Sharybin
Does this mean I get to demand more service from you? :) Congratulations! Morten :) On Mon, Aug 1, 2011 at 9:21 AM, rafa rsaave...@ono.com wrote: Congratulations Sergey !! I wish you the best! El 31/07/11 18:47, Ton Roosendaal escribió: Hi all, I'm really happy to confirm that Sergey accepted a part-time job (30h/ week) to work with Brecht, Campbell and me on general Blender tasks. It is partially to wrap up his SoC project, but especially for all the other jobs that keep lying around, like patch reviewing and bugtracking. He'll start September 1st, at least for four months now. If things work out well, his contract will be continued to be part of the Mango (open movie) developer support team. Welcome Sergey! :) -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands ___ 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] matrix multiplication in Blender SVN of this morning (W32 Vista mingw compiled)
I am with you on this one. Memory layout is one thing. Abstraction is something else entirely. Afterall, one could choose the memory layout to be some crazy fixed random layout or a swizzled layout or whatever. And in both cases there is no reason why, at abstraction level, either one could be considered column or alternatively row major. As an example if the abstraction is column major you'd set translation as a set_column function (and set_row if the api is row major). This can work with any memory layout. To me they are two separate things. (It's implied here that set_column refers to the abstract column). Cheers, Morten. On Wed, Jul 27, 2011 at 6:05 AM, Paul Melis paul.me...@sara.nl wrote: Just chiming in here On 07/27/2011 12:47 PM, Benoit Bolsee wrote: Hi, I repeat once more: mathutils matrices are COLUMN-MAJOR. This means that the top elements in the definition list are columns, not rows, despite the fact that they are printed horizontaly. [...] Mathutils matrices are column-major because that's how Blender stores the matrices internal, and Blender uses that convention because openGL uses it. Why would the textual (or any higher-level representation) have to follow the storage layout? For me those are two distinct concepts and it would be the least confusing to have the matrix representation follow the regular math convention. E.g. http://www.opengl.org/sdk/docs/man/xhtml/glLoadMatrix.xml shows multiplication with a matrix m being loaded as / m[0] m[4] m[8] m[12] \ / v[0] \ M(v) = | m[1] m[5] m[9] m[13] | x | v[1] | | m[2] m[6] m[10] m[14] | | v[2] | \ m[3] m[7] m[11] m[15] / \ v[3] / even though the actual storage order of the matrix is obviously column-major. Secondly, when creating a matrix with Matrix([e1, e2, e3, e4]) I was very surprised to see that the e_i represent columns! Again, this is the storage layout coming through on a higher level, which is confusing. Anyways, just my 2 cents. Regards, Paul ___ 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] matrix multiplication in Blender SVN of this morning (W32 Vista mingw compiled)
well actually I am used to column major myself (at the abstraction level). I only meant I agree that memory layout and abstraction does not have to be the same when it comes to row vs, column major. cheers, Morten. On Wed, Jul 27, 2011 at 7:16 AM, Campbell Barton ideasma...@gmail.comwrote: This is definitely possible with the api (and probably not all that much work) but its quite a big change for some script authors - unlike multiplication order (trivial by comparison). I don't have a sense for whats normal here since I only use mathutils but if this is so confusing and most/all other apis do it ROW-MAJOR then perhaps? Interested to hear other blender devs opinions on this. On Wed, Jul 27, 2011 at 11:56 PM, Morten Mikkelsen mikkels...@gmail.com wrote: I am with you on this one. Memory layout is one thing. Abstraction is something else entirely. Afterall, one could choose the memory layout to be some crazy fixed random layout or a swizzled layout or whatever. And in both cases there is no reason why, at abstraction level, either one could be considered column or alternatively row major. As an example if the abstraction is column major you'd set translation as a set_column function (and set_row if the api is row major). This can work with any memory layout. To me they are two separate things. (It's implied here that set_column refers to the abstract column). Cheers, Morten. On Wed, Jul 27, 2011 at 6:05 AM, Paul Melis paul.me...@sara.nl wrote: Just chiming in here On 07/27/2011 12:47 PM, Benoit Bolsee wrote: Hi, I repeat once more: mathutils matrices are COLUMN-MAJOR. This means that the top elements in the definition list are columns, not rows, despite the fact that they are printed horizontaly. [...] Mathutils matrices are column-major because that's how Blender stores the matrices internal, and Blender uses that convention because openGL uses it. Why would the textual (or any higher-level representation) have to follow the storage layout? For me those are two distinct concepts and it would be the least confusing to have the matrix representation follow the regular math convention. E.g. http://www.opengl.org/sdk/docs/man/xhtml/glLoadMatrix.xml shows multiplication with a matrix m being loaded as / m[0] m[4] m[8] m[12] \ / v[0] \ M(v) = | m[1] m[5] m[9] m[13] | x | v[1] | | m[2] m[6] m[10] m[14] | | v[2] | \ m[3] m[7] m[11] m[15] / \ v[3] / even though the actual storage order of the matrix is obviously column-major. Secondly, when creating a matrix with Matrix([e1, e2, e3, e4]) I was very surprised to see that the e_i represent columns! Again, this is the storage layout coming through on a higher level, which is confusing. Anyways, just my 2 cents. Regards, Paul ___ 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 -- - Campbell ___ 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] matrix multiplication in Blender SVN of this morning (W32 Vista mingw compiled)
This seems like the basis of a religious war...like endianness. Then let's make sure we don't turn it into one. That being said I don't think this should keep us from discussing the subject. It's a relevant issue and we have moderators to deal with spats. Cheers, Morten. Even though I generally like to do things the way mathematicians do it, I'd suggest leaving it the Blender traditional way by default and invite anyone who strongly prefers it the other way to write an API function to switch the sense to math_usual_order within a python routine -- or some other scope that doesn't interact with other code. (This avoids depreciation hassles.) I do think a using very limited scope would make it easier people to follow the code as otherwise they'll get confused about which order. On Wed, Jul 27, 2011 at 10:16 AM, Campbell Barton ideasma...@gmail.com wrote: This is definitely possible with the api (and probably not all that much work) but its quite a big change for some script authors - unlike multiplication order (trivial by comparison). I don't have a sense for whats normal here since I only use mathutils but if this is so confusing and most/all other apis do it ROW-MAJOR then perhaps? Interested to hear other blender devs opinions on this. On Wed, Jul 27, 2011 at 11:56 PM, Morten Mikkelsen mikkels...@gmail.com wrote: I am with you on this one. Memory layout is one thing. Abstraction is something else entirely. Afterall, one could choose the memory layout to be some crazy fixed random layout or a swizzled layout or whatever. And in both cases there is no reason why, at abstraction level, either one could be considered column or alternatively row major. As an example if the abstraction is column major you'd set translation as a set_column function (and set_row if the api is row major). This can work with any memory layout. To me they are two separate things. (It's implied here that set_column refers to the abstract column). Cheers, Morten. On Wed, Jul 27, 2011 at 6:05 AM, Paul Melis paul.me...@sara.nl wrote: Just chiming in here On 07/27/2011 12:47 PM, Benoit Bolsee wrote: Hi, I repeat once more: mathutils matrices are COLUMN-MAJOR. This means that the top elements in the definition list are columns, not rows, despite the fact that they are printed horizontaly. [...] Mathutils matrices are column-major because that's how Blender stores the matrices internal, and Blender uses that convention because openGL uses it. Why would the textual (or any higher-level representation) have to follow the storage layout? For me those are two distinct concepts and it would be the least confusing to have the matrix representation follow the regular math convention. E.g. http://www.opengl.org/sdk/docs/man/xhtml/glLoadMatrix.xml shows multiplication with a matrix m being loaded as / m[0] m[4] m[8] m[12] \ / v[0] \ M(v) = | m[1] m[5] m[9] m[13] | x | v[1] | | m[2] m[6] m[10] m[14] | | v[2] | \ m[3] m[7] m[11] m[15] / \ v[3] / even though the actual storage order of the matrix is obviously column-major. Secondly, when creating a matrix with Matrix([e1, e2, e3, e4]) I was very surprised to see that the e_i represent columns! Again, this is the storage layout coming through on a higher level, which is confusing. Anyways, just my 2 cents. Regards, Paul ___ 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 -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- No essence. No permanence. No perfection. Only action. ___ 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] The dilation I am seeing in Blender is imo not good. I thought I'd propose an alternative (if there's support)?
The dilation I am seeing in Blender is imo not good. I thought I'd propose an alternative (if there's support)? Here's a close-up of the dilation blender does -- http://jbit.net/~sparky/blender_dial/bakezoom_BI_dial.png Here's a close-up of the dilation I was able to do outside of blender using diff. code -- http://jbit.net/~sparky/blender_dial/bakezoom_other_dial.png The bumped visual you get using the first one is this (ugly filtering scar) -- http://jbit.net/~sparky/blender_dial/scr_BI_dial.png The visual you get using the other method is this (significantly more subtle) -- http://jbit.net/~sparky/blender_dial/scr_other_dial.png The blend file to produce the texture is up there -- http://jbit.net/~sparky/blender_dial/bmake.blend This is the full-res baked result you get with dilation using blender -- http://jbit.net/~sparky/blender_dial/bake_BI.png and this is using the alternative dilation -- http://jbit.net/~sparky/blender_dial/bake_other_dial.png I dumped everything here http://jbit.net/~sparky/blender_dial/ incl. a blender file. Let me know what you think. Cheers, Morten. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Mirrored normal maps
You should read the posted comments there under that tutorial. Cheers, Morten. 2011/7/7 Αντώνης Ρυακιωτάκης kal...@gmail.com Recently, this tutorial http://vimeo.com/19461966was brought into my attention which made me wonder if it would be possible to automate the process of applying the same normal map to a symmetrical mesh (More so with the GSoC project of shuvro sarker). Possible ways to do this would be a MTFace option or flag, set by the deform modifier or a tool that detects symmetry. Would you say this is a good/viable approach? ___ 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] Smooth shading could be better (compared to C4D)
Could it be that Cinema4D is using Phong-Shading and Blender is using Gouraud-Shading? Yes that's exactly what you're seeing. You can switch to glsl view if you want to view it in Blender with per pixel lighting. Regular 3D view has to remain fixed function rendering pipeline which implies Gouraud shading. I'd argue there's nothing to look into here (no mystery). Cheers, Morten. On Thu, Jun 16, 2011 at 3:07 PM, Andreas Galster andreas_gals...@hotmail.de wrote: What do you mean? Both C4D's and Blender's normals are pointing in the same direction. Not sure how much vertex normals affect this, but I'm not aware of any way to check vertex normals in C4D. Could it be that Cinema4D is using Phong-Shading and Blender is using Gouraud-Shading? Date: Thu, 16 Jun 2011 16:53:36 -0500 From: xgl.asyl...@gmail.com To: bf-committers@blender.org Subject: Re: [Bf-committers] Smooth shading could be better (compared to C4D) We'd also need to know if normals are coming over with the .obj or are they being calculated once inside Blender? On Thu, Jun 16, 2011 at 3:54 PM, Tom M letter...@gmail.com wrote: would be good to provide a few screenshots so people can see what blender does and what you would like it to do. LetterRip On Thu, Jun 16, 2011 at 12:16 PM, Andreas Galster andreas_gals...@hotmail.de wrote: Today I received a model as an .obj file from Cinema4D to continue working on it, while my workmate is on vacation. It turned out that the smooth shading in Blender highlights/shows shading artifacts due to toplogy (like poles) a lot more than Cinema4D does. Also beveled edges and corners are displayed a lot smoother in C4D. Maybe someone can look into this? Kind regards, Andreas Galster ___ 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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Camera view navigation rant
Also a lock camera to view option would be great so we can just move the camera like we move any other viewport am I the only one that doesn't get this? This is something I would absolutely LOVE to have!! I couldn't agree more. It would be mega helpful. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] bump mapping - white is down black is up???
The way it works now in Blender is just ancient convoluted history. My understanding is that with oldbump (2.49) it never really worked? Meaning it would flip the effect from in to out and vice versa as you bank/rotate the surface relative to the camera right? In which case a consistent choice wasn't really made until newbump from last year which as you say was an abandoned project by the author himself because it was too faulty or tough to manage or whatever. Assuming my understanding of history is correct? Then it seems to me we're not really violating any long withstanding tradition by applying the patch. Morten. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] bump mapping - white is down black is up???
Can't think of any that don't contain the word Blender :) On Tue, Mar 1, 2011 at 11:24 PM, Knapp magick.c...@gmail.com wrote: On Tue, Mar 1, 2011 at 12:34 AM, Daniel Salazar - 3Developer.com zan...@gmail.com wrote: right.. we could come up with a million analogies for one or the other side. Anyway I've done some investigation and the other mainstream software I checked all use white for height an black for down. We could have a fix like the one they did for normal maps cheers Daniel Salazar www.3developer.com I have yet to see one where things get blacker as they go up. Do you have one? Just asking out of fun though. -- Douglas E Knapp Creative Commons Film Group, Helping people make open source movies with open source software! http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php Massage in Gelsenkirchen-Buer: http://douglas.bespin.org/tcm/ztab1.htm Please link to me and trade links with me! Open Source Sci-Fi mmoRPG Game project. http://sf-journey-creations.wikispot.org/Front_Page http://code.google.com/p/perspectiveproject/ ___ 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] bump mapping - white is down black is up???
Just want to make sure everybody realizes I already attached my proposal for a patch in my previous e-mail to this discussion. There's also a comment I put in on why etc. Please check it out. Morten. On Mon, Feb 28, 2011 at 3:34 PM, Daniel Salazar - 3Developer.com zan...@gmail.com wrote: right.. we could come up with a million analogies for one or the other side. Anyway I've done some investigation and the other mainstream software I checked all use white for height an black for down. We could have a fix like the one they did for normal maps cheers Daniel Salazar www.3developer.com 2011/2/28 Sean Olson seanol...@gmail.com: Wow, it seems like this is the rare issue where all seem to be in agreement! Seems white = up, black = down. Though my word does not carry much weight I would like to give a +1 to making it this way. And I might as well throw my little analogy here - For bump mapping I always thought of snow. As snow piles up, things get more white. As snow goes away, things of course turn more brown/black. Yet another of the seemingly endless analogies for black equaling crevasses and white equaling peaks. Hope this proposal goes through! -Sean 2011/2/25 Ρυακιωτάκης Αντώνης kal...@gmail.com I think black=crevice white=peak is the convention too. Most(all?) of the bump-mapping related papers I've seen are written on this premise. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- ||-- Instant Messengers -- || ICQ at 11133295 || AIM at shatterstar98 || MSN Messenger at shatte...@hotmail.com || Yahoo Y! at the_7th_samuri ||-- ___ 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] normal maps, red/green channel inverted
Make it standard please, nmaps are something that you usually share between softwares. no point in forcing headaches to users Daniel Salazar May your first born be a son and may your harvest be plentiful!! :) I could not agree more. That's exactly why this patch needs to go in asap. Normal maps are indeed typically exported between tools. 2011/2/22 Knapp magick.c...@gmail.com: Just provide an external tool or add-on to fix the files. Perhaps pop up a warning: this file has a broken bump-map, run XXX to fix it. On Tue, Feb 22, 2011 at 7:45 PM, Thomas Dinges blen...@dingto.de wrote: I wouldn't do a hackish button either, if it works correct as in 2.49 it's fine and all we need. Am 22.02.2011 19:33, schrieb Ton Roosendaal: Hi all, The situation is worse apparently; up to Blender 2.49 the normal maps were fine, but the newbump patch in 2.51 made red channel become badly inverted. Having it work like in 2.49 is of course correct. Brings up the question if we should provide a hackish button to support bad normal maps created in the alpha/beta period. Morton's Mario's proposal is to not do this. I agree, it only makes UI uglier... :) -Ton- Ton Roosendaal Blender Foundation t...@blender.org www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 20 Feb, 2011, at 14:45, Dalai Felinto wrote: Instead of old Blender Normal maps couldn't it be invert color channels [tooltip: old Blender Normal Maps - invert red/green channels? Or Blender was really the only software out there using those inverted? I remember this being discussed a while ago (1year or +) but don't remember what was the outcome of it. -- Dalai 2011/2/20 Ton Roosendaalt...@blender.org: Hi, I think Carsten's proposal is the nicest way, even when a bit ugly. We can add a version patch in .blend files that sets this button active for all old .blends, but not active for newly created textures. -Ton- Ton Roosendaal Blender Foundation t...@blender.org www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 19 Feb, 2011, at 23:47, Carsten Wartmann wrote: Am 19.02.2011 23:08, schrieb Dalai Felinto: I wonder if instead of a commandline it would be possible to do this conversion with Python. I'm not sure of the current status of bpy for image handling, but it would be neat to have an addon for that. My idea was having a Button inside the Texture Context, Image Tab (beneath the Normal Map Button) to use old Blender Normal maps. Carsten -- Carsten Wartmann: Autor - Dozent - 3D - Grafik Homepage: http://blenderbuch.de/ Das Blender-Buch: http://blenderbuch.de/redirect.html ___ 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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Douglas E Knapp Creative Commons Film Group, Helping people make open source movies with open source software! http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php Massage in Gelsenkirchen-Buer: http://douglas.bespin.org/tcm/ztab1.htm Please link to me and trade links with me! Open Source Sci-Fi mmoRPG Game project. http://sf-journey-creations.wikispot.org/Front_Page http://code.google.com/p/perspectiveproject/ ___ 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] normal maps, red/green channel inverted
Before changing everything again, can we go back to the revision that introduced the change in the first place and maybe understand why it was done? There was probably a reason, even if it wasn't a good one, understanding why might be useful. We already know exactly what is going on. We know exactly how and why the channels have to be set. I promise you. It will conform to the standard that is most common. The old spaces didn't support a real binormal (meaning +/- sign was not maintained). It was rather broken as it was. It was almost luck whether you got one thing or another. This is also why it was essentially useless for exporting any normal map out of blender. A new system has already been put in place which replaces the generated tangent spaces. These support mirroring and a sign +/-1 to create a bitangent with the correct orientation. This is not something mindlessly thrown in at the last minute. Martin --- On Tue, 2/22/11, Sean Olson seanol...@gmail.com wrote: From: Sean Olson seanol...@gmail.com Subject: Re: [Bf-committers] normal maps, red/green channel inverted To: bf-blender developers bf-committers@blender.org Received: Tuesday, February 22, 2011, 4:35 PM I also could not agree more. Some standardization here would get rid of plenty of headaches. To be clear, the step that I would like to avoid is under: GIMPing the image on this page: http://www.foro3d.com/f217/blender-normal-mapping-76567.html (It's basically just instructing to invert the green channel) http://www.foro3d.com/f217/blender-normal-mapping-76567.htmlI believe it worked this way in 2.49 and currently works this way also though I have not tested very recently. If I recall the results of the last mailing list conversation on this subject, the consensus was that there is no 'standard' on ways to do normal mapping so Blender's is as good as anybody else's, and is not technically 'wrong'. The problem is that most of the other apps have standardized in 'the other method'. I tried tracking the email thread down, but after about an hour of digging have given up. -Sean On Tue, Feb 22, 2011 at 12:26 PM, Morten Mikkelsen mikkels...@gmail.com wrote: Make it standard please, nmaps are something that you usually share between softwares. no point in forcing headaches to users Daniel Salazar May your first born be a son and may your harvest be plentiful!! :) I could not agree more. That's exactly why this patch needs to go in asap. Normal maps are indeed typically exported between tools. 2011/2/22 Knapp magick.c...@gmail.com: Just provide an external tool or add-on to fix the files. Perhaps pop up a warning: this file has a broken bump-map, run XXX to fix it. On Tue, Feb 22, 2011 at 7:45 PM, Thomas Dinges blen...@dingto.de wrote: I wouldn't do a hackish button either, if it works correct as in 2.49 it's fine and all we need. Am 22.02.2011 19:33, schrieb Ton Roosendaal: Hi all, The situation is worse apparently; up to Blender 2.49 the normal maps were fine, but the newbump patch in 2.51 made red channel become badly inverted. Having it work like in 2.49 is of course correct. Brings up the question if we should provide a hackish button to support bad normal maps created in the alpha/beta period. Morton's Mario's proposal is to not do this. I agree, it only makes UI uglier... :) -Ton- Ton Roosendaal Blender Foundation t...@blender.org www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 20 Feb, 2011, at 14:45, Dalai Felinto wrote: Instead of old Blender Normal maps couldn't it be invert color channels [tooltip: old Blender Normal Maps - invert red/green channels? Or Blender was really the only software out there using those inverted? I remember this being discussed a while ago (1year or +) but don't remember what was the outcome of it. -- Dalai 2011/2/20 Ton Roosendaalt...@blender.org: Hi, I think Carsten's proposal is the nicest way, even when a bit ugly. We can add a version patch in .blend files that sets this button active for all old .blends, but not active for newly created textures. -Ton- Ton Roosendaal Blender Foundation t...@blender.org www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 19
[Bf-committers] normal maps, red/green channel inverted
Hi all, Blender is exporting normal maps with red and green channel inverted relative to the geometry we actually export with our exporters and I would very much like to fix this. This would make blender export normal maps which are very similar to most tools out there and it would make sense to people trying to use them in their own engines. What we are talking about is a very minor tweak. There's one place that writes them and two places that read them. I would only have to do a minor adjustment there. It will be different from maps baked with blender previously but then that ship has already sailed when we gave normal maps the overhaul that we did to support mirroring, order-independence of faces, vertices on faces, welding etc. So when you think about it this is a relatively minor tweak in comparison. So I am thinking might as well do it proper. Kaito has asked me to ask you guys if you are ok with it? Here's hoping for the best :) Thanks, Morten, ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] normal maps, red/green channel inverted
This does mean that old scenes render incorrect? Just to clarify. Or will there be some compatibility switch? Mario (lmg) suggests we'll throw in a commandline for how to do batch convert in image magic. The inversion we're talking about corresponds to ctrl+i in photoshop btw. It's essentially (in 8 bit): val_new = 255 - val_cur; applied to red and green. This will make the normals stored in the map correspond to tangent space generated from the geometry we actually export in all of our exporters. Like I said since we have already done an overhaul on how normal maps work to get them to work properly and support mirroring, face/face verts order-independence, welding independence etc. We might as well be sure to get it right now. Seems like now or never, And this is a small adjustment on the change that is already in anyway. Cheers, Morten. On Sat, Feb 19, 2011 at 7:51 AM, Carsten Wartmann c...@blenderbuch.de wrote: Am 19.02.2011 16:22, schrieb Morten Mikkelsen: Hi all, Blender is exporting normal maps with red and green channel inverted relative to the geometry we actually export with our exporters and I would very much like to fix this. This would make blender export normal maps which are very similar to most tools out there and it would make sense to people trying to use them in their own engines. Good! It will be different from maps baked with blender previously but then that This does mean that old scenes render incorrect? Just to clarify. Or will there be some compatibility switch? Carsten Kaito has asked me to ask you guys if you are ok with it? Who's that guy hanging around there all the time? ;-) -- Carsten Wartmann: Autor - Dozent - 3D - Grafik Homepage: http://blenderbuch.de/ Das Blender-Buch: http://blenderbuch.de/redirect.html ___ 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
