[Bf-committers] Opensubdiv and catmull-clark again
Hi. I just mentioned that Blender's subdivision surface is acting a little bit different than opensubdiv. It's noticable when using creases on geometry like this: http://puu.sh/la3Xw/3c06b8b687.png Blender's catmull-clark subdivs: http://puu.sh/la3ZJ/a5f8ce2ddf.png Opensubdiv: http://puu.sh/la40E/529b72bec5.png Looks like Blender's Catmull-Clark subdivs are not Catmull-Clark subdivs... ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] macrovellum's fluid designer for linux
hello, i hope that i write to the right address. i contacted "microvellum" about the release of "fluid designer" for linux, and thats the answer i've received: "Unfortunately we were never able to get the Linux Build working because Blender doesn’t provide complete documentation on how redistribute a Linux version. Once Blender has finished documenting this then we will provide a Linux build. Sorry for the inconvenience. If you would like you can compile the source code yourself by following the steps below." and afterwards, to my question if "fluid designer" can be ported at least for ubuntu: "When building for any Linux Distribution we need to statically link all of the libraries that Blender uses, and they don’t provide a list of all of the libraries that need to be linked. We will continue to try to figure out all of the necessary libraries that Blender uses. Once we have a working Linux version we will let you know." is it possible someway to help "macrovellum" release the linux version of "fluid designer" - windows and mac users can already benefit from that program and linux users can not! thanks, sincerely, N.T. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Opensubdiv and catmull-clark again
intersting, in that case, as a modeler i would prefer the open subv result, however i didnt model that much using it, the performance its much much better, but the shading its "weird" or not accurate on most cases. . . i need to test it more to shape an opinion PasteAll.org - opensubdiv.jpg | | | | | | | | | PasteAll.org - opensubdiv.jpgPasteAll.org - opensubdiv.jpg opensubdiv.jpg ~0.11mb..ish. 916 px. 1335 px. |< << hi PasteAll.org is brought to you by the monkeys of GraphicAll.org - | | | | Ver en www.pasteall.org | Vista previa por Yahoo | | | | | El Jueves, 5 de noviembre, 2015 5:09:30, Yury Baranov escribió: Hi. I just mentioned that Blender's subdivision surface is acting a little bit different than opensubdiv. It's noticable when using creases on geometry like this: http://puu.sh/la3Xw/3c06b8b687.png Blender's catmull-clark subdivs: http://puu.sh/la3ZJ/a5f8ce2ddf.png Opensubdiv: http://puu.sh/la40E/529b72bec5.png Looks like Blender's Catmull-Clark subdivs are not Catmull-Clark subdivs... ___ 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] Opensubdiv and catmull-clark again
Opensubdiv is unusable ATM in fact. Problems are: 1. Unable to apply Subsurf with OSD enabled. Result is identical to Subsurf without OSD check. 2. Shading is wrong (bug is in the bugtracker already). OSD takes normals for shading from lowpoly instead of computing new normals. 3. No UV subdivision. 4. GLSL Compute is not working for me. OK, the feature is too new and too raw to use it in production. But OSD is based on Catmull-Clark algo, which is already used in the Subsurf modifier, OSD is just speeding mesh calculation up. The problem is, OSD and Catmull-Clark subdiv models look different, it not supposed to happen IMHO. 2015-11-05 15:33 GMT+03:00 Nahuel Belich : > intersting, in that case, as a modeler i would prefer the open subv > result, however i didnt model that much using it, the performance its much > much better, but the shading its "weird" or not accurate on most cases. . . > i need to test it more to shape an opinion > PasteAll.org - opensubdiv.jpg > | | > | | | | | | > | PasteAll.org - opensubdiv.jpgPasteAll.org - opensubdiv.jpg > opensubdiv.jpg ~0.11mb..ish. 916 px. 1335 px. |< << hi PasteAll.org is > brought to you by the monkeys of GraphicAll.org - | > | | > | Ver en www.pasteall.org | Vista previa por Yahoo | > | | > | | > > > > > > El Jueves, 5 de noviembre, 2015 5:09:30, Yury Baranov < > cucumbe...@gmail.com> escribió: > > > Hi. I just mentioned that Blender's subdivision surface is acting a little > bit different than opensubdiv. It's noticable when using creases on > geometry like this: http://puu.sh/la3Xw/3c06b8b687.png > Blender's catmull-clark subdivs: http://puu.sh/la3ZJ/a5f8ce2ddf.png > Opensubdiv: http://puu.sh/la40E/529b72bec5.png > > Looks like Blender's Catmull-Clark subdivs are not Catmull-Clark subdivs... > ___ > 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] Some Ideas for a Blender Plugin System
- Cython does not have as much performance as pure C/C++ - Python is still the best choice for prototyping and pipeline stuff - C/C++ API can be used for better performance without having the nightmare to dive into Blender core code to just add one modifier Most of the modifier we are developping in Maya are first done in Python, but then it is port to C++ for performance matter. Same approach would be nice in Blender. Of course we can modify Blender code and recompile it but : - this is low level coding compare to the use of an API - can make future merge more complicated for a studio And in some cases like sharing code for importer/exporter in alembic, fbx would be more easier if it was done as a plugin rather than being embeded in our blender build 2015-11-04 14:44 GMT+01:00 Diego Gangl : > Hi all, > > What would be the benefit of doing this, instead of expanding the python > api? > > The only case I can think of is doing really complex computations or > working with large sets of data, and you already have three options for > that: > > - Use numpy (for some things) > - Use Cython > - Start a process from python and communicate with pipes > > A plugin/module system might sound great on paper, but I think it would be > a nightmare of corner cases. > > > > > > > > > > > > > 2015-11-04 4:58 GMT-03:00 Sybren A. Stüvel : > > > On Tue, Nov 03, 2015 at 08:04:03PM +0100, matmenu wrote: > > > 2) Do you have a proof for this claim? I mean, modifier/operator > > > combinations already lead to bugs, I don't see why having them as > > > plugins/modules would make those problems arise more often? > > > > I don't understand your reasoning. To me it reads like "we get bugs > > now, so why would we get more when we complicate the software?" In the > > current situation there is a fixed set of functionality in C++ > > (ignoring precompiler directives). In the case of a plugin structure, > > not only do we have the same set of functionality, but also situations > > where that functionality is only partially loaded. More different > > possible situations -> more complex -> more bugs. > > > > > 3) That's true, but then the user decide to install this module, so > > > he will report the bug to the original dev > > > > This is only true if the bug is trivial to to identify by end-users. > > Plenty of bugs won't be. Think about double-free bugs, where the first > > free is performed in the plugin. A crash may happen when Blender > > itself frees the pointer, and thus any traceback (if that's shown at > > all) will indicate a problem in Blender, not the plugin. > > > > > 4) Also true, but we now have a buildbot that can make builds on > > > demand for all supported OS. It could be used further by > > > module/plugin devs and avoid having to ship a compiler with Blender. > > > > AFAIK FreeBSD is not built by this system. Furthermore, allowing > > arbitrary third party code to be run on a BI/BF-hosted machine is an > > invitation for trouble. This already happens, but through the Git > > repository, so at least it's only done by people that have been vetted > > by receiving commit access. > > > > -- > > Sybren A. Stüvel > > > > http://stuvelfoto.nl/ > > http://stuvel.eu/ > > > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > > > -- > -- > Diego Gangl - sinestesia.co > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- François Tarlier www.francois-tarlier.com www.linkedin.com/in/francoistarlier ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Some Ideas for a Blender Plugin System
Hi all, If we want to go for speed. On Thu, Nov 5, 2015 at 3:16 PM, François T. wrote: > - Cython does not have as much performance as pure C/C++ > While this is true even making the RNA api accessible through cython would be a step up compared to current situation > - Python is still the best choice for prototyping and pipeline stuff > - C/C++ API can be used for better performance without having the nightmare > to dive into Blender core code to just add one modifier > Main problem I see here is that keeping such an API stable is a non trivial job > > Most of the modifier we are developping in Maya are first done in Python, > but then it is port to C++ for performance matter. Same approach would be > nice in Blender. > > > And in some cases like sharing code for importer/exporter in alembic, fbx > would be more easier if it was done as a plugin rather than being embeded > in our blender build > As we discussed on the blender conference I think your Alembic work might actually be useful by attempting to port it to our existing RNA C++-API and see what work needs to be done on that API in that way. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Opensubdiv and catmull-clark again
Hi guys, I'm actively working on OpenSubdiv, especially getting it running on more systems (Intel gfx on Windows, Mac). GLSL compute works on the latest version of OSD (official Blender release doesn't use this yet). Similar performance to Transform Feedback. The other problems you mention... yep those are still problems. Thanks for pointing out #2 -- I knew it looked odd but didn't make the connection to low-poly normals. Can you give a link to the bug tracker? From my understanding, OpenSubdiv will become *the* subsurf implementation in Blender, and the old system will go away. But first we need to fix these problems. Mike Erwin musician, naturalist, pixel pusher, hacker extraordinaire On Thu, Nov 5, 2015 at 7:52 AM, Yury Baranov wrote: > Opensubdiv is unusable ATM in fact. Problems are: > 1. Unable to apply Subsurf with OSD enabled. Result is identical to Subsurf > without OSD check. > 2. Shading is wrong (bug is in the bugtracker already). OSD takes normals > for shading from lowpoly instead of computing new normals. > 3. No UV subdivision. > 4. GLSL Compute is not working for me. > OK, the feature is too new and too raw to use it in production. But OSD is > based on Catmull-Clark algo, which is already used in the Subsurf modifier, > OSD is just speeding mesh calculation up. The problem is, OSD and > Catmull-Clark subdiv models look different, it not supposed to happen IMHO. > > 2015-11-05 15:33 GMT+03:00 Nahuel Belich : > > > intersting, in that case, as a modeler i would prefer the open subv > > result, however i didnt model that much using it, the performance its > much > > much better, but the shading its "weird" or not accurate on most cases. > . . > > i need to test it more to shape an opinion > > PasteAll.org - opensubdiv.jpg > > | | > > | | | | | | > > | PasteAll.org - opensubdiv.jpgPasteAll.org - opensubdiv.jpg > > opensubdiv.jpg ~0.11mb..ish. 916 px. 1335 px. |< << hi PasteAll.org is > > brought to you by the monkeys of GraphicAll.org - | > > | | > > | Ver en www.pasteall.org | Vista previa por Yahoo | > > | | > > | | > > > > > > > > > > > > El Jueves, 5 de noviembre, 2015 5:09:30, Yury Baranov < > > cucumbe...@gmail.com> escribió: > > > > > > Hi. I just mentioned that Blender's subdivision surface is acting a > little > > bit different than opensubdiv. It's noticable when using creases on > > geometry like this: http://puu.sh/la3Xw/3c06b8b687.png > > Blender's catmull-clark subdivs: http://puu.sh/la3ZJ/a5f8ce2ddf.png > > Opensubdiv: http://puu.sh/la40E/529b72bec5.png > > > > Looks like Blender's Catmull-Clark subdivs are not Catmull-Clark > subdivs... > > ___ > > 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] macrovellum's fluid designer for linux
Hi, >> Once Blender has finished documenting this then we will provide a Linux build That is true, but you can't really have it finished. It changes every so often actually so it's hard to have step-by-step reproduceable instructions of how to reproduce up-to-date release environment. However, there is some documentation which should be good enough for the starting point. >> When building for any Linux Distribution we need to statically link all of the libraries that Blender uses Static linking is actually highly discouraged by all the main Linux distors in favor of linking against shared libraries provided by the packages. So if you know, for example, you're aiming latest Ubuntu you can easily do it by simply compiling blender on the system where only packages from the distro are installed. The only reason Blender is using special environment is because we want single binary to be runnable on all the machines up to 10 years old, which requires special tricks to make it all working, mainly due to libc library. I would also mention here that i wrote notes about how i set up original Linux release environment there [1]. There is even setup script which i tried to keep up to date to certain point, for until it became real hassle to maintain. It could easily be used for the starting point [2]. >> They don’t provide a list of all of the libraries that need to be linked We do have same exact configuration used for release builds and buildbot builds, so you can easily get configuration used for the release from SCons configs [3]. >> is it possible someway to help "macrovellum" release the linux version of "fluid designer" Why not ask them to contact us directly? [1] http://wiki.blender.org/index.php/User:Nazg-gul/LinuxBuildbotEnvironment [2] https://developer.blender.org/diffusion/B/browse/master/build_files/build_environment/prepare_release_env.sh [3] https://developer.blender.org/diffusion/B/browse/master/build_files/buildbot/config/ On Thu, Nov 5, 2015 at 1:27 PM, lansha graphics wrote: > hello, i hope that i write to the right address. > i contacted "microvellum" about the release of "fluid designer" for linux, > and thats the answer i've received: > > "Unfortunately we were never able to get the Linux Build working because > Blender doesn’t provide complete documentation on how redistribute a Linux > version. Once Blender has finished documenting this then we will provide a > Linux build. Sorry for the inconvenience. If you would like you can compile > the source code yourself by following the steps below." > > and afterwards, to my question if "fluid designer" can be ported at least > for ubuntu: > > "When building for any Linux Distribution we need to statically link all > of the libraries that Blender uses, and they don’t provide a list of all of > the libraries that need to be linked. We will continue to try to figure out > all of the necessary libraries that Blender uses. Once we have a working > Linux version we will let you know." > > is it possible someway to help "macrovellum" release the linux version of > "fluid designer" - windows and mac users can already benefit from that > program and linux users can not! > > thanks, > sincerely, N.T. > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Opensubdiv and catmull-clark again
Yury, For the original mail: OpenSubdiv and Blender original CCGSubSurf are using different approaches to the patch topology construction, but both of them technically are Catmull-Clark subdivisions. There's no correct or wrong crease here, it's just different and behaves better in one situation or another. We'll switch to OpenSubdiv completely once all the issues are solved. For the followup mail: you're pointing out all the TODOs and limitations mentioned in the original release page [1]. Don't see much reason to discuss them here, we'll need to work on this still. With a project size of OpenSubdiv and the tight release schedule we had so far you can't really have everything to be ideally supported from the first commit. It'll all come eventually. Mike, GLSL Compute is disabled for AMD devices because original OSD library we used for the 2.76-rc1 had a bug on AMD hardware. It was fixed later at rc2 or rc3 from the OpenSubdiv side, but we can't bump library versions at the RC stage (bumping it will mean we're allowing to use hardware which was known to be buggy without too much tests done first). For the shading, here's the bug report [2]. I didn't find a way to evaluate limit surface on the GPU when using non-adaptive subdivisions and i didn't really heard back from Pixar about how it could be done. Wold need to ask the guys again. But OpenSubdiv 3.0 is quite fresh so far and perhaps non-adaptive case is not high priority for them yet. Perhaps we can do some other trickery to get better normals, but that'd requite having tessellation control and evaluation shaders which was quite hard to do with current OpenGL state we've got. It didn't quite work for me when trying to sue it as an #extension for glsl 1.3 and mumping glsl to 1.4 and higher would mean re-writting all the existing shaders (due to removed of loads of deprecated stuff in it, i.e. gl_Normal). Maybe you can have some other ideas here tho. [1] http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.76/OpenSubdiv [2] https://developer.blender.org/T45707 On Thu, Nov 5, 2015 at 10:02 PM, Mike Erwin wrote: > Hi guys, > I'm actively working on OpenSubdiv, especially getting it running on more > systems (Intel gfx on Windows, Mac). GLSL compute works on the latest > version of OSD (official Blender release doesn't use this yet). Similar > performance to Transform Feedback. The other problems you mention... yep > those are still problems. > > Thanks for pointing out #2 -- I knew it looked odd but didn't make the > connection to low-poly normals. Can you give a link to the bug tracker? > > From my understanding, OpenSubdiv will become *the* subsurf implementation > in Blender, and the old system will go away. But first we need to fix these > problems. > > Mike Erwin > musician, naturalist, pixel pusher, hacker extraordinaire > > On Thu, Nov 5, 2015 at 7:52 AM, Yury Baranov wrote: > > > Opensubdiv is unusable ATM in fact. Problems are: > > 1. Unable to apply Subsurf with OSD enabled. Result is identical to > Subsurf > > without OSD check. > > 2. Shading is wrong (bug is in the bugtracker already). OSD takes normals > > for shading from lowpoly instead of computing new normals. > > 3. No UV subdivision. > > 4. GLSL Compute is not working for me. > > OK, the feature is too new and too raw to use it in production. But OSD > is > > based on Catmull-Clark algo, which is already used in the Subsurf > modifier, > > OSD is just speeding mesh calculation up. The problem is, OSD and > > Catmull-Clark subdiv models look different, it not supposed to happen > IMHO. > > > > 2015-11-05 15:33 GMT+03:00 Nahuel Belich : > > > > > intersting, in that case, as a modeler i would prefer the open subv > > > result, however i didnt model that much using it, the performance its > > much > > > much better, but the shading its "weird" or not accurate on most cases. > > . . > > > i need to test it more to shape an opinion > > > PasteAll.org - opensubdiv.jpg > > > | | > > > | | | | | | > > > | PasteAll.org - opensubdiv.jpgPasteAll.org - opensubdiv.jpg > > > opensubdiv.jpg ~0.11mb..ish. 916 px. 1335 px. |< << hi PasteAll.org is > > > brought to you by the monkeys of GraphicAll.org - | > > > | | > > > | Ver en www.pasteall.org | Vista previa por Yahoo | > > > | | > > > | | > > > > > > > > > > > > > > > > > > El Jueves, 5 de noviembre, 2015 5:09:30, Yury Baranov < > > > cucumbe...@gmail.com> escribió: > > > > > > > > > Hi. I just mentioned that Blender's subdivision surface is acting a > > little > > > bit different than opensubdiv. It's noticable when using creases on > > > geometry like this: http://puu.sh/la3Xw/3c06b8b687.png > > > Blender's catmull-clark subdivs: http://puu.sh/la3ZJ/a5f8ce2ddf.png > > > Opensubdiv: http://puu.sh/la40E/529b72bec5.png > > > > > > Looks like Blender's Catmull-Clark subdivs are not Catmull-Clark > > subdivs... > > > ___ > > > Bf-committers mailing list > > > Bf-committ
Re: [Bf-committers] Opensubdiv and catmull-clark again
Hi Sergey! I wasn't suggesting the latest OSD should have been rushed into 2.76. But definitely for the next update. I've upgraded Blender to OSD 3.0.3 locally and it fixes GLSL compute for both AMD and Intel on Windows. Adaptive subdivision doesn't seem to work on Intel chips -- on Windows or Mac -- even with Pixar's example programs. No crash or errors; the surface just doesn't appear on screen. Non-adaptive works fine. How soon can we bump the libs to 3.0.3? I have a few changes to the Blender-OSD glue. Can those go into master or would you prefer a new branch for the stuff I'll be working on? No ideas yet for the normals but I will investigate. As you know we're moving to GLSL 1.5 soon so rewriting is going to happen anyway. Mike Erwin musician, naturalist, pixel pusher, hacker extraordinaire On Thu, Nov 5, 2015 at 11:22 PM, Sergey Sharybin wrote: > Yury, > > For the original mail: OpenSubdiv and Blender original CCGSubSurf are using > different approaches to the patch topology construction, but both of them > technically are Catmull-Clark subdivisions. There's no correct or wrong > crease here, it's just different and behaves better in one situation or > another. We'll switch to OpenSubdiv completely once all the issues are > solved. > > For the followup mail: you're pointing out all the TODOs and limitations > mentioned in the original release page [1]. Don't see much reason to > discuss them here, we'll need to work on this still. With a project size of > OpenSubdiv and the tight release schedule we had so far you can't really > have everything to be ideally supported from the first commit. It'll all > come eventually. > > Mike, > > GLSL Compute is disabled for AMD devices because original OSD library we > used for the 2.76-rc1 had a bug on AMD hardware. It was fixed later at rc2 > or rc3 from the OpenSubdiv side, but we can't bump library versions at the > RC stage (bumping it will mean we're allowing to use hardware which was > known to be buggy without too much tests done first). > > For the shading, here's the bug report [2]. I didn't find a way to evaluate > limit surface on the GPU when using non-adaptive subdivisions and i didn't > really heard back from Pixar about how it could be done. Wold need to ask > the guys again. But OpenSubdiv 3.0 is quite fresh so far and perhaps > non-adaptive case is not high priority for them yet. > > Perhaps we can do some other trickery to get better normals, but that'd > requite having tessellation control and evaluation shaders which was quite > hard to do with current OpenGL state we've got. It didn't quite work for me > when trying to sue it as an #extension for glsl 1.3 and mumping glsl to 1.4 > and higher would mean re-writting all the existing shaders (due to removed > of loads of deprecated stuff in it, i.e. gl_Normal). Maybe you can have > some other ideas here tho. > > [1] > http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.76/OpenSubdiv > [2] https://developer.blender.org/T45707 > > > > On Thu, Nov 5, 2015 at 10:02 PM, Mike Erwin > wrote: > > > Hi guys, > > I'm actively working on OpenSubdiv, especially getting it running on more > > systems (Intel gfx on Windows, Mac). GLSL compute works on the latest > > version of OSD (official Blender release doesn't use this yet). Similar > > performance to Transform Feedback. The other problems you mention... yep > > those are still problems. > > > > Thanks for pointing out #2 -- I knew it looked odd but didn't make the > > connection to low-poly normals. Can you give a link to the bug tracker? > > > > From my understanding, OpenSubdiv will become *the* subsurf > implementation > > in Blender, and the old system will go away. But first we need to fix > these > > problems. > > > > Mike Erwin > > musician, naturalist, pixel pusher, hacker extraordinaire > > > > On Thu, Nov 5, 2015 at 7:52 AM, Yury Baranov > wrote: > > > > > Opensubdiv is unusable ATM in fact. Problems are: > > > 1. Unable to apply Subsurf with OSD enabled. Result is identical to > > Subsurf > > > without OSD check. > > > 2. Shading is wrong (bug is in the bugtracker already). OSD takes > normals > > > for shading from lowpoly instead of computing new normals. > > > 3. No UV subdivision. > > > 4. GLSL Compute is not working for me. > > > OK, the feature is too new and too raw to use it in production. But OSD > > is > > > based on Catmull-Clark algo, which is already used in the Subsurf > > modifier, > > > OSD is just speeding mesh calculation up. The problem is, OSD and > > > Catmull-Clark subdiv models look different, it not supposed to happen > > IMHO. > > > > > > 2015-11-05 15:33 GMT+03:00 Nahuel Belich : > > > > > > > intersting, in that case, as a modeler i would prefer the open subv > > > > result, however i didnt model that much using it, the performance its > > > much > > > > much better, but the shading its "weird" or not accurate on most > cases. > > > . . > > > > i need to test it more to shape an opinion > > > > Past
Re: [Bf-committers] Opensubdiv and catmull-clark again
Issues with upstream development branch of OpenSubdiv are to be reported to their github tracker [1]. We will go to latest OpenSubdiv as soon as i catch up with real life after all this flying. Hopefully for the Monday-Tuesday we'll have updated libs for all the supported platforms. [1] https://github.com/PixarAnimationStudios/OpenSubdiv/issues On Fri, Nov 6, 2015 at 11:03 AM, Mike Erwin wrote: > Hi Sergey! > > I wasn't suggesting the latest OSD should have been rushed into 2.76. But > definitely for the next update. I've upgraded Blender to OSD 3.0.3 locally > and it fixes GLSL compute for both AMD and Intel on Windows. Adaptive > subdivision doesn't seem to work on Intel chips -- on Windows or Mac -- > even with Pixar's example programs. No crash or errors; the surface just > doesn't appear on screen. Non-adaptive works fine. > > How soon can we bump the libs to 3.0.3? I have a few changes to the > Blender-OSD glue. Can those go into master or would you prefer a new branch > for the stuff I'll be working on? > > No ideas yet for the normals but I will investigate. As you know we're > moving to GLSL 1.5 soon so rewriting is going to happen anyway. > > Mike Erwin > musician, naturalist, pixel pusher, hacker extraordinaire > > On Thu, Nov 5, 2015 at 11:22 PM, Sergey Sharybin > wrote: > > > Yury, > > > > For the original mail: OpenSubdiv and Blender original CCGSubSurf are > using > > different approaches to the patch topology construction, but both of them > > technically are Catmull-Clark subdivisions. There's no correct or wrong > > crease here, it's just different and behaves better in one situation or > > another. We'll switch to OpenSubdiv completely once all the issues are > > solved. > > > > For the followup mail: you're pointing out all the TODOs and limitations > > mentioned in the original release page [1]. Don't see much reason to > > discuss them here, we'll need to work on this still. With a project size > of > > OpenSubdiv and the tight release schedule we had so far you can't really > > have everything to be ideally supported from the first commit. It'll all > > come eventually. > > > > Mike, > > > > GLSL Compute is disabled for AMD devices because original OSD library we > > used for the 2.76-rc1 had a bug on AMD hardware. It was fixed later at > rc2 > > or rc3 from the OpenSubdiv side, but we can't bump library versions at > the > > RC stage (bumping it will mean we're allowing to use hardware which was > > known to be buggy without too much tests done first). > > > > For the shading, here's the bug report [2]. I didn't find a way to > evaluate > > limit surface on the GPU when using non-adaptive subdivisions and i > didn't > > really heard back from Pixar about how it could be done. Wold need to ask > > the guys again. But OpenSubdiv 3.0 is quite fresh so far and perhaps > > non-adaptive case is not high priority for them yet. > > > > Perhaps we can do some other trickery to get better normals, but that'd > > requite having tessellation control and evaluation shaders which was > quite > > hard to do with current OpenGL state we've got. It didn't quite work for > me > > when trying to sue it as an #extension for glsl 1.3 and mumping glsl to > 1.4 > > and higher would mean re-writting all the existing shaders (due to > removed > > of loads of deprecated stuff in it, i.e. gl_Normal). Maybe you can have > > some other ideas here tho. > > > > [1] > > http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.76/OpenSubdiv > > [2] https://developer.blender.org/T45707 > > > > > > > > On Thu, Nov 5, 2015 at 10:02 PM, Mike Erwin > > wrote: > > > > > Hi guys, > > > I'm actively working on OpenSubdiv, especially getting it running on > more > > > systems (Intel gfx on Windows, Mac). GLSL compute works on the latest > > > version of OSD (official Blender release doesn't use this yet). Similar > > > performance to Transform Feedback. The other problems you mention... > yep > > > those are still problems. > > > > > > Thanks for pointing out #2 -- I knew it looked odd but didn't make the > > > connection to low-poly normals. Can you give a link to the bug tracker? > > > > > > From my understanding, OpenSubdiv will become *the* subsurf > > implementation > > > in Blender, and the old system will go away. But first we need to fix > > these > > > problems. > > > > > > Mike Erwin > > > musician, naturalist, pixel pusher, hacker extraordinaire > > > > > > On Thu, Nov 5, 2015 at 7:52 AM, Yury Baranov > > wrote: > > > > > > > Opensubdiv is unusable ATM in fact. Problems are: > > > > 1. Unable to apply Subsurf with OSD enabled. Result is identical to > > > Subsurf > > > > without OSD check. > > > > 2. Shading is wrong (bug is in the bugtracker already). OSD takes > > normals > > > > for shading from lowpoly instead of computing new normals. > > > > 3. No UV subdivision. > > > > 4. GLSL Compute is not working for me. > > > > OK, the feature is too new and too raw to use it in production. But > OSD > > > i
Re: [Bf-committers] macrovellum's fluid designer for linux
Hello, Sergey, thanx for answering. I already told them to contact this mail list, i hope they'll do. till than i will transform them your answer. Sincerely, N.T. 06.11.2015, 07:07, "Sergey Sharybin" : > Hi, > >>> Once Blender has finished documenting this then we will provide a Linux > > build > > That is true, but you can't really have it finished. It changes every so > often actually so it's hard to have step-by-step reproduceable instructions > of how to reproduce up-to-date release environment. However, there is some > documentation which should be good enough for the starting point. > >>> When building for any Linux Distribution we need to statically link all > > of the libraries that Blender uses > > Static linking is actually highly discouraged by all the main Linux distors > in favor of linking against shared libraries provided by the packages. So > if you know, for example, you're aiming latest Ubuntu you can easily do it > by simply compiling blender on the system where only packages from the > distro are installed. The only reason Blender is using special environment > is because we want single binary to be runnable on all the machines up to > 10 years old, which requires special tricks to make it all working, mainly > due to libc library. > > I would also mention here that i wrote notes about how i set up original > Linux release environment there [1]. There is even setup script which i > tried to keep up to date to certain point, for until it became real hassle > to maintain. It could easily be used for the starting point [2]. > >>> They don’t provide a list of all of the libraries that need to be linked > > We do have same exact configuration used for release builds and buildbot > builds, so you can easily get configuration used for the release from SCons > configs [3]. > >>> is it possible someway to help "macrovellum" release the linux version > > of "fluid designer" > > Why not ask them to contact us directly? > > [1] http://wiki.blender.org/index.php/User:Nazg-gul/LinuxBuildbotEnvironment > [2] > https://developer.blender.org/diffusion/B/browse/master/build_files/build_environment/prepare_release_env.sh > [3] > https://developer.blender.org/diffusion/B/browse/master/build_files/buildbot/config/ > > On Thu, Nov 5, 2015 at 1:27 PM, lansha graphics > wrote: > >> hello, i hope that i write to the right address. >> i contacted "microvellum" about the release of "fluid designer" for linux, >> and thats the answer i've received: >> >> "Unfortunately we were never able to get the Linux Build working because >> Blender doesn’t provide complete documentation on how redistribute a Linux >> version. Once Blender has finished documenting this then we will provide a >> Linux build. Sorry for the inconvenience. If you would like you can compile >> the source code yourself by following the steps below." >> >> and afterwards, to my question if "fluid designer" can be ported at least >> for ubuntu: >> >> "When building for any Linux Distribution we need to statically link all >> of the libraries that Blender uses, and they don’t provide a list of all of >> the libraries that need to be linked. We will continue to try to figure out >> all of the necessary libraries that Blender uses. Once we have a working >> Linux version we will let you know." >> >> is it possible someway to help "macrovellum" release the linux version of >> "fluid designer" - windows and mac users can already benefit from that >> program and linux users can not! >> >> thanks, >> sincerely, N.T. >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers > > -- > With best regards, Sergey Sharybin > ___ > 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] Opensubdiv and catmull-clark again
Cool, I just opened OpenSubdiv issue #757 for adaptive tessellation on Intel. Also have an open bug in Apple's bug tracker, re-reported as OpenSubdiv issue #758. Mike Erwin musician, naturalist, pixel pusher, hacker extraordinaire On Fri, Nov 6, 2015 at 1:12 AM, Sergey Sharybin wrote: > Issues with upstream development branch of OpenSubdiv are to be reported to > their github tracker [1]. > > We will go to latest OpenSubdiv as soon as i catch up with real life after > all this flying. Hopefully for the Monday-Tuesday we'll have updated libs > for all the supported platforms. > > > [1] https://github.com/PixarAnimationStudios/OpenSubdiv/issues > > On Fri, Nov 6, 2015 at 11:03 AM, Mike Erwin > wrote: > > > Hi Sergey! > > > > I wasn't suggesting the latest OSD should have been rushed into 2.76. But > > definitely for the next update. I've upgraded Blender to OSD 3.0.3 > locally > > and it fixes GLSL compute for both AMD and Intel on Windows. Adaptive > > subdivision doesn't seem to work on Intel chips -- on Windows or Mac -- > > even with Pixar's example programs. No crash or errors; the surface just > > doesn't appear on screen. Non-adaptive works fine. > > > > How soon can we bump the libs to 3.0.3? I have a few changes to the > > Blender-OSD glue. Can those go into master or would you prefer a new > branch > > for the stuff I'll be working on? > > > > No ideas yet for the normals but I will investigate. As you know we're > > moving to GLSL 1.5 soon so rewriting is going to happen anyway. > > > > Mike Erwin > > musician, naturalist, pixel pusher, hacker extraordinaire > > > > On Thu, Nov 5, 2015 at 11:22 PM, Sergey Sharybin > > wrote: > > > > > Yury, > > > > > > For the original mail: OpenSubdiv and Blender original CCGSubSurf are > > using > > > different approaches to the patch topology construction, but both of > them > > > technically are Catmull-Clark subdivisions. There's no correct or wrong > > > crease here, it's just different and behaves better in one situation or > > > another. We'll switch to OpenSubdiv completely once all the issues are > > > solved. > > > > > > For the followup mail: you're pointing out all the TODOs and > limitations > > > mentioned in the original release page [1]. Don't see much reason to > > > discuss them here, we'll need to work on this still. With a project > size > > of > > > OpenSubdiv and the tight release schedule we had so far you can't > really > > > have everything to be ideally supported from the first commit. It'll > all > > > come eventually. > > > > > > Mike, > > > > > > GLSL Compute is disabled for AMD devices because original OSD library > we > > > used for the 2.76-rc1 had a bug on AMD hardware. It was fixed later at > > rc2 > > > or rc3 from the OpenSubdiv side, but we can't bump library versions at > > the > > > RC stage (bumping it will mean we're allowing to use hardware which was > > > known to be buggy without too much tests done first). > > > > > > For the shading, here's the bug report [2]. I didn't find a way to > > evaluate > > > limit surface on the GPU when using non-adaptive subdivisions and i > > didn't > > > really heard back from Pixar about how it could be done. Wold need to > ask > > > the guys again. But OpenSubdiv 3.0 is quite fresh so far and perhaps > > > non-adaptive case is not high priority for them yet. > > > > > > Perhaps we can do some other trickery to get better normals, but that'd > > > requite having tessellation control and evaluation shaders which was > > quite > > > hard to do with current OpenGL state we've got. It didn't quite work > for > > me > > > when trying to sue it as an #extension for glsl 1.3 and mumping glsl to > > 1.4 > > > and higher would mean re-writting all the existing shaders (due to > > removed > > > of loads of deprecated stuff in it, i.e. gl_Normal). Maybe you can have > > > some other ideas here tho. > > > > > > [1] > > > > http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.76/OpenSubdiv > > > [2] https://developer.blender.org/T45707 > > > > > > > > > > > > On Thu, Nov 5, 2015 at 10:02 PM, Mike Erwin > > > > wrote: > > > > > > > Hi guys, > > > > I'm actively working on OpenSubdiv, especially getting it running on > > more > > > > systems (Intel gfx on Windows, Mac). GLSL compute works on the latest > > > > version of OSD (official Blender release doesn't use this yet). > Similar > > > > performance to Transform Feedback. The other problems you mention... > > yep > > > > those are still problems. > > > > > > > > Thanks for pointing out #2 -- I knew it looked odd but didn't make > the > > > > connection to low-poly normals. Can you give a link to the bug > tracker? > > > > > > > > From my understanding, OpenSubdiv will become *the* subsurf > > > implementation > > > > in Blender, and the old system will go away. But first we need to fix > > > these > > > > problems. > > > > > > > > Mike Erwin > > > > musician, naturalist, pixel pusher, hacker extraordinaire > > > > > > > > On Thu, Nov 5
