Re: [Bf-committers] BConf VR Meeting Notes
Ok Dalai, Hope this can be adressed else where. No matter what, vr in Blender is a big deal. Happy to see it evolving. Em sex, 1 de nov de 2019 14:44, Dalai Felinto escreveu: > Hi Adriano, > > The VR project has little overlap with the EEVEE stereo requirements. > > The only place they share some common requirements, is in regard to fisheye > support in the viewport. For EEVEE panorama/fisheye we need to map the > mouse with the pointer in the projected image. For VR we need something > similar to map 3d controllers to sculpting, drawing, ... > > Regards, > Dalai > > Em sex, 1 de nov de 2019 às 10:01, Adriano Oliveira < > adriano.u...@gmail.com> > escreveu: > > > Great news! > > > > Will this in some way addres an aproach to allow Eevee to export stereo > > panoramas/cubes with screen space effects support? > > > > In raster renders this is usually accomplished by composing a lot of thin > > render slices. That can be done by an addon, but I think it would be more > > optmimizad in blender code. > > > > This can help: > > https://developers.google.com/vr/jump/rendering-ods-content.pdf > > > > *Adriano A. Oliveira* > > > > > > < > > > https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail > > > > > Livre > > de vírus. www.avast.com > > < > > > https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail > > >. > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > > > Em ter, 29 de out de 2019 às 08:21, Julian Eisel > > escreveu: > > > > > Hi all, > > > > > > we had a VR meeting during the conference, here are the notable bits. > > > > > > Attendees > > > > > > * Dalai Felinto (Blender Foundation) > > > * Damien Coureau (Ubisoft) > > > * Daniel Martinez Lara (Pepe School Land & MPX) > > > * Julian Eisel (Blender Institute) > > > * Julien Blervaque (Ubisoft) > > > * Sebastian König (blendFX) > > > * Simeon Conzendorf (blendFX) > > > * William Reynish (Blender Foundation) > > > > > > General Requirements > > > = > > > * There will have to be some experimenting with different approaches > > > to XR UIs. People and studios also have very different needs for XR > > > experiences. > > > * Just how we define the regular 2D UIs in Python, XR UIs should be > > > defined in Python as well. That allows extending and specializing the > > > UIs for custom needs. The Ubisoft team is especially keen on this. > > > * Blender should bundle a good default XR UI for common usage, > > > established through experimentation of the core VR team and other > > > collaborators. > > > * With the gizmo, operator and drawing APIs, the BPY already has many > > > of the needed bits. There's still lots of stuff we'd have to figure > > > out and add to it though. > > > > > > Next Steps > > > > > > * The team agrees on building the VR UI around specific use-cases. > > > * The GSoC patch [1] should be merged with the first basic use-case > > > working (scene inspection, see below) > > > * We'll start with the following use-cases (roughly in that order): > > >1. Scene Introspection - VR viewport with initial/simple navigation > > >2. Sculpting & Grease Pencil drawing in VR > > >3. Set arrangement/layout - Support adding primitives, transforming > > > objects and some related gizmos > > >4. Complete immersive toolset (aka MARUI) > > >5. VR Storyboarding - Support changing cameras, time and animation > > > timing within the VR session > > >6. Set dressing - Support adding particles, assets, ... > > > * Besides the first use-case, the involved "Blender core developers" > > > will only try to provide the frameworks needed to implement the other > > > use-cases. These can then be picked up by contributors (e.g. the > > > Ubisoft, MARUI or MPX teams). > > > * The project will be organized as usual in Blender, with a landing > > > page on developer.blender.org, clearly stated priorities and > > > milestones, and visible ways for contributors to get involved. > > > > > > Future > > > = > > > * We also want to support AR/MR based use-cases. > > > * Collaborative sessions form other important use-cases: multiple > > > people with multiple h
Re: [Bf-committers] BConf VR Meeting Notes
Great news! Will this in some way addres an aproach to allow Eevee to export stereo panoramas/cubes with screen space effects support? In raster renders this is usually accomplished by composing a lot of thin render slices. That can be done by an addon, but I think it would be more optmimizad in blender code. This can help: https://developers.google.com/vr/jump/rendering-ods-content.pdf *Adriano A. Oliveira* <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> Livre de vírus. www.avast.com <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>. <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> Em ter, 29 de out de 2019 às 08:21, Julian Eisel escreveu: > Hi all, > > we had a VR meeting during the conference, here are the notable bits. > > Attendees > > * Dalai Felinto (Blender Foundation) > * Damien Coureau (Ubisoft) > * Daniel Martinez Lara (Pepe School Land & MPX) > * Julian Eisel (Blender Institute) > * Julien Blervaque (Ubisoft) > * Sebastian König (blendFX) > * Simeon Conzendorf (blendFX) > * William Reynish (Blender Foundation) > > General Requirements > = > * There will have to be some experimenting with different approaches > to XR UIs. People and studios also have very different needs for XR > experiences. > * Just how we define the regular 2D UIs in Python, XR UIs should be > defined in Python as well. That allows extending and specializing the > UIs for custom needs. The Ubisoft team is especially keen on this. > * Blender should bundle a good default XR UI for common usage, > established through experimentation of the core VR team and other > collaborators. > * With the gizmo, operator and drawing APIs, the BPY already has many > of the needed bits. There's still lots of stuff we'd have to figure > out and add to it though. > > Next Steps > > * The team agrees on building the VR UI around specific use-cases. > * The GSoC patch [1] should be merged with the first basic use-case > working (scene inspection, see below) > * We'll start with the following use-cases (roughly in that order): >1. Scene Introspection - VR viewport with initial/simple navigation >2. Sculpting & Grease Pencil drawing in VR >3. Set arrangement/layout - Support adding primitives, transforming > objects and some related gizmos >4. Complete immersive toolset (aka MARUI) >5. VR Storyboarding - Support changing cameras, time and animation > timing within the VR session >6. Set dressing - Support adding particles, assets, ... > * Besides the first use-case, the involved "Blender core developers" > will only try to provide the frameworks needed to implement the other > use-cases. These can then be picked up by contributors (e.g. the > Ubisoft, MARUI or MPX teams). > * The project will be organized as usual in Blender, with a landing > page on developer.blender.org, clearly stated priorities and > milestones, and visible ways for contributors to get involved. > > Future > = > * We also want to support AR/MR based use-cases. > * Collaborative sessions form other important use-cases: multiple > people with multiple headsets work together in the same XR viewport. > This is a rather complicated use-case to get supported, but it would > be immensely useful. > > > [1] - https://developer.blender.org/D5537 > > Cheers, > - Julian - > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Eevee Add and Multiply Blend modes in 2.81
Hi developers, Any reason way Eevee transparency blend modes ADD and MULTIPLY were removed in 2.81? >From my point of view, they are very important. Thank you for the great work! *Adriano A. Oliveira* ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Eevee raytraced (cycles) shadows
Hi guys, First of all, congratulations for the outstanding work in 2.8. We all can see how Eevee is becoming a major improvement for certain kind of animation production, especially for TV shows. For now, the big concern is real time shadows. I don't know how far we can go here, but I see some room for having Cycles rendering only raytraced shadows for composing over Eevee renders in post. Is there a way to optimize that in terms of speed and workflow? *Adriano A. Oliveira* ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.8 interface reference: Substance Painter 2018.1 (Spring)
Well Ricardo, I do not think you should turn my "[global] reference suggestion" into a "proposal". In a recent interview, Ton pointed out Substance Painter's interface as an example of good solutions. I am just stating that it has been updated. *Adriano A. Oliveira* 2018-03-16 15:38 GMT-03:00 Ricardo Nunes <3rto...@gmail.com>: > 1) What exactly do you think is better between this and the old SP > interface (Maybe as a hyphen list?) > 2) Which parts exactly do you think are applicable to Blender (The new UI > style like in the slider buttons etc, do you mean how when closing floating > windows the get minimized to icons on the sides of the viewport, do you > mean how window splitting works?) > 3) How exactly do you think they should be applied to Blender? (Should we > change sliders/buttons to have similar style? Should we have T/N menus > changed to be more like the dock minimization? Similar drop down in 3D view > for individual texture channels? Should we have similar drop down for > wireframe, solid, textured, rendered?) > It'd be a lot of work for the devs just to figure out what you think should > be adapted from SP even before formulating it into proposal and starting to > work on it if you just drop a video without context of what the video > improved on and what is good about it and what of it you think could be > adapted. > Well although I'm newbie to the whole FOSS community so not that I know but > that's what it seems like to me. > > 2018-03-16 15:37 GMT+02:00 Adriano Oliveira <adriano.u...@gmail.com>: > > > Hi guys, > > > > Just want to sugest Substance Painter 2018's new interface as solutions > > references for the work to be done in 2.8. Very good revamp of an already > > good interface. > > > > https://youtu.be/UG3XOMuy7ec > > > > ;) > > > > > > *Adriano A. Oliveira* > > > > <https://www.avast.com/sig-email?utm_medium=email_ > > source=link_campaign=sig-email_content=webmail> > > Livre > > de vírus. www.avast.com > > <https://www.avast.com/sig-email?utm_medium=email_ > > source=link_campaign=sig-email_content=webmail>. > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > https://lists.blender.org/mailman/listinfo/bf-committers > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> Livre de vírus. www.avast.com <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>. <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] 2.8 interface reference: Substance Painter 2018.1 (Spring)
Hi guys, Just want to sugest Substance Painter 2018's new interface as solutions references for the work to be done in 2.8. Very good revamp of an already good interface. https://youtu.be/UG3XOMuy7ec ;) *Adriano A. Oliveira* <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> Livre de vírus. www.avast.com <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>. <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Baking Princlipled/PBR maps and lightmaps for Eevee
Thank you, Clément. I understand your point. Congratulations for the outstanding achievements so far. <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> Livre de vírus. www.avast.com <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>. <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> *Adriano A. Oliveira* Coordenador do Colegiado do Curso de Cinema e Audiovisual Universidade Federal do Recôncavo da Bahia (UFRB) Centro de Artes Humanidades e Letras (CAHL) Matrícula: 1673892 (71) 99181-0123 [VIVO] 2018-02-14 11:09 GMT-03:00 Clément FOUCAULT <foucault.c...@gmail.com>: > HI Adriano, > > Lightmap support in eevee is not trivial. If you just want to bake the > irradiance (diffuse) in cycles and use it in eevee you can add an emission > node with the lightmap multiplied by the diffuse color, and set the > diffuse color in other bsdf nodes to black. > > And creating really good lightmaps system is not easy. We would need to > encode the lighting directionallity and I don't even know if cycles can do > that. Also managing instances UV offsets/scalling/packing is another > problem. > > It's not in our short term goals for sure. > > Regards. > > 2018-02-14 14:21 GMT+01:00 Adriano Oliveira <adriano.u...@gmail.com>: > > > Hi, > > > > Cycles bake was a great thing implemented by Dalai. With the workflows > > pointing out to PBR, I hope we have some time for adjustments/additions. > > > > This is my contributions (not asking for/demanding anything): > > > > 1. The Cycles bake workflow is not intuitive. The need for a image > texture > > node alone selected in the shader is not ideal. Good addons like TexTools > > solve this, but I think it should be addressed in 2.8 with new depsgraph. > > > > 2. We should be able to bake some missing real PBR maps: Roughness, > > Metallic... (Ok, we can already do it manually in most scenarios). > > > > 3. We need to Bake Cycles Lightmaps (32bits). This is a real deal for > > Eevee. Baked Shadows are not enough. Plus, objects with lightmaps should > > not be affected by Eevee Irradiance Volume and static lights. > > > > Hope we can get there somewhere in time. ;) > > > > > > *Adriano* > > > > <https://www.avast.com/sig-email?utm_medium=email_ > > source=link_campaign=sig-email_content=webmail> > > Livre > > de vírus. www.avast.com > > <https://www.avast.com/sig-email?utm_medium=email_ > > source=link_campaign=sig-email_content=webmail>. > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > https://lists.blender.org/mailman/listinfo/bf-committers > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Baking Princlipled/PBR maps and lightmaps for Eevee
Hi, Cycles bake was a great thing implemented by Dalai. With the workflows pointing out to PBR, I hope we have some time for adjustments/additions. This is my contributions (not asking for/demanding anything): 1. The Cycles bake workflow is not intuitive. The need for a image texture node alone selected in the shader is not ideal. Good addons like TexTools solve this, but I think it should be addressed in 2.8 with new depsgraph. 2. We should be able to bake some missing real PBR maps: Roughness, Metallic... (Ok, we can already do it manually in most scenarios). 3. We need to Bake Cycles Lightmaps (32bits). This is a real deal for Eevee. Baked Shadows are not enough. Plus, objects with lightmaps should not be affected by Eevee Irradiance Volume and static lights. Hope we can get there somewhere in time. ;) *Adriano* <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> Livre de vírus. www.avast.com <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>. <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Patch: OCIO Parse Colorspace From Filename
Excelent, Ray! <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> Livre de vírus. www.avast.com <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>. <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> *Adriano A. Oliveira* Coordenador do Colegiado do Curso de Cinema e Audiovisual Universidade Federal do Recôncavo da Bahia (UFRB) Centro de Artes Humanidades e Letras (CAHL) Matrícula: 1673892 (71) 99181-0123 [VIVO] 2017-12-11 17:38 GMT-03:00 Ray Molenkamp <r...@lazydodo.com>: > Most of the things asked can be done from an add on, with no core changes > needed, > I quickly whipped one up (tested only on windows). not the prettiest code > around but > it shows the concept can work. > > Also it saves a ton of clicks by only having to open a single texture in a > set, and it'll do > its best to figure out the related textures. > > https://github.com/LazyDodo/MultiInput > > --Ray > > On 12/10/2017 10:48 PM, Troy Sobotka wrote: > > Greets. > > > > In response to the thread regarding the tedium of manual setting of > colour > > spaces, > > I've created this patch that leverages OpenColorIO's > > parseColorSpaceFromString > > functionality. > > > > With this patch, filenames such as rubber_srgb.png, > treealbedo_linear.tiff, > > facescan_acescg.tiff, etc. will all honour the colourspace if it is found > > in the > > given configuration. > > > > https://developer.blender.org/differential/diff/9682/ > > > > With respect, > > TJS > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > https://lists.blender.org/mailman/listinfo/bf-committers > > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Patch: OCIO Parse Colorspace From Filename
Hi people, I think this is ok, but do not really address "the tedium of manual setting of color spaces". No one would change two clicks in a drop down menu by a lot of typing in texture names: "_sRGB", "_linear"... It would be better to add sensitive conditions to names that we already use in PBR texture workflow: "_albedo" or "_basecolor" (=sRGB/gamma 2.2); "_rough", "metalic", "_ao"... (=linear). And maybe we should separate the color management for textures nodes and the color management in media input for composing purposes. In Blender composition workflow, like in Natron em Nuke, beeing able to set color spaces for incoming media is fundamental, and they can vary a lot and will vary a lot more in future (REC2020...) But textures at material setting context are not as complicated. We just have two effective scenarios: linear or sRGB (gamma corrected). Everything should be linear for maps, but as long as we stay with old 256 levels per channel, gamma correct is needed for color textures due to compression. The future in this area is everything linear texture at 16 or 32 bit, not a profusion of color spaces (who knows...). That is why a "[ ] sRGB" or "[ ] gamma corrected" check box in Texture Image node is the ideal solution for the unnecessary drop down for only two color space in this context. *Adriano A. Oliveira* 2017-12-11 12:12 GMT-03:00 Xavier Thomas <xavier.thomas.1...@gmail.com>: > > > > This patch seems to have the following priority: > > - Image loader sets color space (based on either image header or other > > assumptions) > > - The higher level reader then might override the color space based on > file > > name. > > If we allow such an automatic guess, it should be other way around. If > the > > file knows it's color space, it should be trusted, as it is more trustful > > than a file name. > > > Then it might be wiser to join all the "color space auto detection magic" > at the same place (image loader) and only try to guess from the filename if > the header/metadata detection failed. > > In any case, in my opinion, the colorspace displayed in the UI/RNA > (possibly manually set by the user afterwards) should always be respected > and never silently overridden. > > Xavier > > 2017-12-11 12:45 GMT-02:00 Troy Sobotka <troy.sobo...@gmail.com>: > > > On Mon, Dec 11, 2017, 5:57 AM Sergey Sharybin <sergey@gmail.com> > > wrote: > > > - Image loader sets color space (based on either image header or other > > > assumptions) > > > The higher level reader then might override the color space based on > file > > > name. > > > > > If we allow such an automatic guess, it should be other way around. If > > the > > > file knows it's color space, it should be trusted, as it is more > trustful > > > than a file name. > > > > > > > Ok. So if we do that, what is the best method to set the defaults? Each > > filetype has the colourspace set to the default role. > > > > Would the following order work? > > > > * Set the filetype default to Null. > > * Test the colorspace variable for a Blender file setting. > > * If Blender file remains unset, test for filename. > > * If it remains unset, set to default role. > > > > Is there a means to differentiate between whether the colorspace variable > > was set via default role or user based setting? > > > > With respect, > > TJS > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > https://lists.blender.org/mailman/listinfo/bf-committers > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> Livre de vírus. www.avast.com <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>. <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Some suggestions for nodes' interface revision in PBR times
Dears, I would like to suggest some reviews for IMAGE TEXTURE and NORMAL MAP nodes interface to help with PBR workflow. This could be implemented in 2.8. 1. COLOR SPACE. Today we need to open a drop down menu and pick color (sRGB) / non-color (linear). In a PBR workflow, most of textures should be linear (roughness, metallic, normal map, ambient occlusion etc) and only albedo/base color is usually a sRGB bitmap. Therefore, we need to perform 2 clicks over the majority of textures we import... A better approach would be to have just a check box for "[ ] sRGB", like in Unreal. If it is checked (default), color space is gamma corrected, if it is not, it is linear. Believe me, when you have a scene with dozens of PBR material, this is a huge time saving. 2. RGB output slots [not as needed as above]. Now we have COLOR and ALPHA outputs from a Image Texture node. In PBR workflows is very common to merge gray scale maps into the four channels of a RGBA texture. It would be nice to have as outputs COLOR, R, G, B and ALPHA, like in Unreal. [This can be done via Separate RGB, of course]. 3. INVERT GREEN / Y in NORMAL MAP node. There are two standards today for normal maps: OpenGL (Blender) and DirectX. Most systems offers a check box to invert direction of the Y channel. Bake in Blender does, so it seems reasonable to have it in NM also. Best regards, *Adriano A. Oliveira* ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Eevee rendering clamped 0-1 images
Thank you! *Adriano A. Oliveira* Coordenador do Colegiado do Curso de Cinema e Audiovisual Universidade Federal do Recôncavo da Bahia (UFRB) Centro de Artes Humanidades e Letras (CAHL) Matrícula: 1673892 (71) 99181-0123 [VIVO] / (71) 99146-8523 [TIM] 2017-06-20 9:31 GMT-03:00 Clément FOUCAULT <foucault.c...@gmail.com>: > Yes it's completely work in progress. > > Final output will be unclamped and not already tonemapped. > > Regards. > > 2017-06-19 17:57 GMT+02:00 Adriano Oliveira <adriano.u...@gmail.com>: > > > Hi guys, > > > > First of all, congratulations to Dalai and Clémant for the outstanding > > Eevee progress so far. > > > > I just would like to know how do you plant to deal with HDR values from > > Eevee on viewport and renders. > > > > Right now (last week build) I understand that Eevee is clamped in 0-1 > > values, what limits Filmic tone mapping and post production, for > instance. > > Is it something temporary? > > > > Best regards, > > > > *Adriano A. Oliveira* > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > https://lists.blender.org/mailman/listinfo/bf-committers > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Eevee rendering clamped 0-1 images
Hi guys, First of all, congratulations to Dalai and Clémant for the outstanding Eevee progress so far. I just would like to know how do you plant to deal with HDR values from Eevee on viewport and renders. Right now (last week build) I understand that Eevee is clamped in 0-1 values, what limits Filmic tone mapping and post production, for instance. Is it something temporary? Best regards, *Adriano A. Oliveira* ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Please add invert green channel option in Normal Map node
@Mike Cycles bake already has a toggle like this for export. We need this in Normal Map node to deal with NM textures baked for DirectX. Game engines like Unity and Unreal have an "invert green (y) channel" option in texture properties. In my workflow, for instance, I model and animate in Blander, texture in Substance Painter and render in Unreal. In Painter I export Normal Map textures to Unreal with DirectX standard (inverted green channel in relation do OpenGL standard). If I need to see my model with this texture in Blender, I have to create a node setup to invert G before feeding Normal Map node. *Adriano A. Oliveira* Professor Adjunto do Curso de Cinema e Audiovisual Universidade Federal do Recôncavo da Bahia (UFRB) Centro de Artes Humanidades e Letras (CAHL) Matrícula: 1673892 (71) 99181-0123 [VIVO] / (71) 99146-8523 [TIM] 2017-04-15 15:01 GMT-03:00 patrick boelens <p_boel...@msn.com>: > I actually just ran into a case where I wanted to compare the custom > normals I set up in Blender to those inside another app, so there is a > use-case for real-time toggling as well. > > > No idea how prevalent it is and whether it's worth the effort though, but > figured I'd chime in. > > > Cheers, > > Patrick > > > Van: bf-committers-boun...@blender.org <bf-committers-boun...@blender.org> > namens Mike Erwin <significant@gmail.com> > Verzonden: zaterdag 15 april 2017 04:49:08 > Aan: bf-blender developers > Onderwerp: Re: [Bf-committers] Please add invert green channel option in > Normal Map node > > On Fri, Apr 14, 2017 at 10:47 AM, Adriano Oliveira <adriano.u...@gmail.com > > > wrote: > > > I just miss one little thing: An check box option to invert textures' > green > > chennels in the Normal Map node. > > > > This is very important because Blender follow the OpenGL norms for Normal > > Map, but other softwares that may be integrated within a pipeline (like > > Unreal) uses DirectX norms. > > > > Is this only needed during import & export, or something you would toggle > during the Blender session? > > Mike Erwin > musician, naturalist, pixel pusher, hacker extraordinaire > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Please add invert green channel option in Normal Map node
Hi guys, I tresure very much all initiatives to integrate Blender in the PBR workflow for games and films, like Envee and Principled (Disney) Shader. I just miss one little thing: An check box option to invert textures' green chennels in the Normal Map node. This is very important because Blender follow the OpenGL norms for Normal Map, but other softwares that may be integrated within a pipeline (like Unreal) uses DirectX norms. PS: I know I can do it myself with separete rgb - invert green - composite rgb... Thank you in advance. Adriano A. Oliveira <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> Livre de vírus. www.avast.com <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>. <#m_-1137370312128584813_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Alembic triangulation
François, Shaders are not as important as meterials per face assignments. Unreal imports materias names and assingnments form Blender Alembics, but Maya and 3dMax don't. I think it is related to Blender and Unreal beeing Alembic 1.6. An update of my findings so far: https://forums.unrealengine.com/showthread.php?120948-Blender-2-78-Alembic-Unreal-4-13 *Adriano* 2016-08-22 11:45 GMT-03:00 François T. <francoistarl...@gmail.com>: > Alembic doesn't contain any information about the unit. You have to make it > a convention in your project. If in blender 1 unit = 1 meter for you, then > you need to set the proper unit system in Maya which will be in cm at the > system level. We did a patch on the alembic I/O of Maya (you can find it on > the alembic github) which use the unit of the maya scene rather than > assuming that the alembic is in cm (which what is the default I/O in maya > does). But know that Alembic only stores generic unit. > > For materials, there is no such information in Alembic file format. Only > shading groups (or material assignation per face as you might name it). So > you cannot exchange shaders or material parameters with Alembic. You will > need a script in your dcc which binds a material based on it's name and the > shading group stored in the Alembic. (alembic is just a geometry cache) > > cheers, > > F. > > 2016-08-20 14:51 GMT+02:00 Adriano Oliveira <adriano.u...@gmail.com>: > > > Kévin, > > > > I treasure your Alembic iniciative and I wish to help. I am just > performing > > some tests before judging what it is or is not a bug. In the prosses I > will > > give some constructive feedback here. > > > > Blender-Alembic-Blender seams ok. I am performing some testes in this > > plataforms: Unreal 4.13, 3ds Max 2017 (educational), Maya 2017 > > (educational). > > > > Findings on importing Alembic character animation from Blender: > > > > 1. Unreal 4.13 (preview 2): Issues with rotation (y-z) and scale (cm-m). > > Bad normals from Blender (ok from Max). Animation and meshes are ok. > > > > 2. 3ds Max 2017 (Educational): Rotation/sacale ok. Bad normals. No > > materials. Animation and meshes are ok. > > > > 3. Maya... soon... > > > > > > At this moment, I would say that normals are problematic. > > > > I will report bugs as soon as I have solid tests. > > > > > > > > *Adriano A. Oliveira* > > Professor Adjunto do Curso de Cinema e Audiovisual > > Universidade Federal do Recôncavo da Bahia (UFRB) > > Centro de Artes Humanidades e Letras (CAHL) > > Matrícula: 1673892 > > (71) 99181-0123 [VIVO] / (71) 99146-8523 [TIM] > > > > 2016-08-19 23:56 GMT-03:00 Kévin Dietrich <kevin.dietr...@mailoo.org>: > > > > > Please use the bug tracker [1] to report bugs/issues, with simple > > > example files to reproduces them. > > > > > > If one software can open an Alembic file from Blender without issues, > > > and another can't, for basic things like normals, then the bug is > mostly > > > likely in the other software, not Blender, we don't do anything fancy > > > here. Also, can 3ds Max import materials from other software without > > > issues? > > > > > > Le 2016-08-20 04:38, Adriano Oliveira a écrit : > > > > > > > > > > > > > > > bf48750 > > > > > > > > 3) Bad normals when importing from Blender-Alembic into Unreal 4.13 > and > > > 3ds > > > > Mac 2017. > > > > > > > > 4) 3ds Max doesn't import materials from Blender-Alembic. Unreal 4.13 > > > does. > > > > > > > > *Adriano A. Oliveira* > > > > Professor Adjunto do Curso de Cinema e Audiovisual > > > > Universidade Federal do Recôncavo da Bahia (UFRB) > > > > Centro de Artes Humanidades e Letras (CAHL) > > > > Matrícula: 1673892 > > > > (71) 99181-0123 [VIVO] / (71) 99146-8523 [TIM] > > > > > > > > 2016-08-19 19:36 GMT-03:00 Adriano Oliveira <adriano.u...@gmail.com > >: > > > > > > > > Kévin, > > > > > > > > I am very interested in the workflow Blender-Unreal through Alembic. > > The > > > > idea is to use Unreal for real time rendering. > > > > Alembic in Unreal 4.13 is in preview state, so it will improve a lot. > > > > > > > > Some findings: > > > > > > > > 1) Alembic is very usefull to export destruction simulations. I used > > Cell > > > > Fracture to explode a cube
Re: [Bf-committers] Alembic triangulation
Kévin, I treasure your Alembic iniciative and I wish to help. I am just performing some tests before judging what it is or is not a bug. In the prosses I will give some constructive feedback here. Blender-Alembic-Blender seams ok. I am performing some testes in this plataforms: Unreal 4.13, 3ds Max 2017 (educational), Maya 2017 (educational). Findings on importing Alembic character animation from Blender: 1. Unreal 4.13 (preview 2): Issues with rotation (y-z) and scale (cm-m). Bad normals from Blender (ok from Max). Animation and meshes are ok. 2. 3ds Max 2017 (Educational): Rotation/sacale ok. Bad normals. No materials. Animation and meshes are ok. 3. Maya... soon... At this moment, I would say that normals are problematic. I will report bugs as soon as I have solid tests. *Adriano A. Oliveira* Professor Adjunto do Curso de Cinema e Audiovisual Universidade Federal do Recôncavo da Bahia (UFRB) Centro de Artes Humanidades e Letras (CAHL) Matrícula: 1673892 (71) 99181-0123 [VIVO] / (71) 99146-8523 [TIM] 2016-08-19 23:56 GMT-03:00 Kévin Dietrich <kevin.dietr...@mailoo.org>: > Please use the bug tracker [1] to report bugs/issues, with simple > example files to reproduces them. > > If one software can open an Alembic file from Blender without issues, > and another can't, for basic things like normals, then the bug is mostly > likely in the other software, not Blender, we don't do anything fancy > here. Also, can 3ds Max import materials from other software without > issues? > > Le 2016-08-20 04:38, Adriano Oliveira a écrit : > > > > > > > bf48750 > > > > 3) Bad normals when importing from Blender-Alembic into Unreal 4.13 and > 3ds > > Mac 2017. > > > > 4) 3ds Max doesn't import materials from Blender-Alembic. Unreal 4.13 > does. > > > > *Adriano A. Oliveira* > > Professor Adjunto do Curso de Cinema e Audiovisual > > Universidade Federal do Recôncavo da Bahia (UFRB) > > Centro de Artes Humanidades e Letras (CAHL) > > Matrícula: 1673892 > > (71) 99181-0123 [VIVO] / (71) 99146-8523 [TIM] > > > > 2016-08-19 19:36 GMT-03:00 Adriano Oliveira <adriano.u...@gmail.com>: > > > > Kévin, > > > > I am very interested in the workflow Blender-Unreal through Alembic. The > > idea is to use Unreal for real time rendering. > > Alembic in Unreal 4.13 is in preview state, so it will improve a lot. > > > > Some findings: > > > > 1) Alembic is very usefull to export destruction simulations. I used Cell > > Fracture to explode a cube and it produces houndreds of n-gons objects. > On > > importing into Unreal, it gives errors. I think this would justify an > > triangulation option, as in OBJ export. > > > > 2) I have some crashes on importing Alembic animated characters into > > Blender or Unreal that was exported without Flatten Hierarchy. > > > > ;) > > > > *Adriano A. Oliveira* > > Professor Adjunto do Curso de Cinema e Audiovisual > > Universidade Federal do Recôncavo da Bahia (UFRB) > > Centro de Artes Humanidades e Letras (CAHL) > > Matrícula: 1673892 > > (71) 99181-0123 [VIVO] / (71) 99146-8523 [TIM] > > > > 2016-08-19 19:10 GMT-03:00 Kévin Dietrich <kevin.dietr...@mailoo.org>: > > > > Le 2016-08-19 23:53, Adriano Oliveira a écrit : > > > > Hi, > > > > Is it possible to have an option to triangulate mesh on Alembic export. > I am trying to import a animation from Blender to Unreal 4.13 and the late > > ask for tri or quad faces. > > > > Also it would be nice to have Z to Y convertion options, as long as > Unreal rotates the Alembic imports form Blender. > > > > Congratulations for the grate job! > > > > *Adriano A. Oliveira* > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > https://lists.blender.org/mailman/listinfo/bf-committers > > Hi, > > > > Adding an option to triangulate meshes in the exporter wouldn't that > > much of a trouble (though it would have to wait for after the 2.78 > > release), but I have to ask what prevents you from triangulating the > > meshes before exporting? If you've got a lot of objects to triangulate, > > a simple Python script can be written to automate the process. Shall it > > be a destructive operation, or shall it preserve the state of the meshes > > (meaning meshes in Blender are not triangulated, but the exported ones > > are)? > > > > For the axis conversion, Alembic files written from Blender follow the > > Alembic Y-up convention, so I guess this is already what you want? I do > > plan on addin
Re: [Bf-committers] Alembic triangulation
bf48750 3) Bad normals when importing from Blender-Alembic into Unreal 4.13 and 3ds Mac 2017. 4) 3ds Max doesn't import materials from Blender-Alembic. Unreal 4.13 does. *Adriano A. Oliveira* Professor Adjunto do Curso de Cinema e Audiovisual Universidade Federal do Recôncavo da Bahia (UFRB) Centro de Artes Humanidades e Letras (CAHL) Matrícula: 1673892 (71) 99181-0123 [VIVO] / (71) 99146-8523 [TIM] 2016-08-19 19:36 GMT-03:00 Adriano Oliveira <adriano.u...@gmail.com>: > Kévin, > > I am very interested in the workflow Blender-Unreal through Alembic. The > idea is to use Unreal for real time rendering. > Alembic in Unreal 4.13 is in preview state, so it will improve a lot. > > Some findings: > > 1) Alembic is very usefull to export destruction simulations. I used Cell > Fracture to explode a cube and it produces houndreds of n-gons objects. On > importing into Unreal, it gives errors. I think this would justify an > triangulation option, as in OBJ export. > > 2) I have some crashes on importing Alembic animated characters into > Blender or Unreal that was exported without Flatten Hierarchy. > > ;) > > > > *Adriano A. Oliveira* > Professor Adjunto do Curso de Cinema e Audiovisual > Universidade Federal do Recôncavo da Bahia (UFRB) > Centro de Artes Humanidades e Letras (CAHL) > Matrícula: 1673892 > (71) 99181-0123 [VIVO] / (71) 99146-8523 [TIM] > > 2016-08-19 19:10 GMT-03:00 Kévin Dietrich <kevin.dietr...@mailoo.org>: > >> Le 2016-08-19 23:53, Adriano Oliveira a écrit : >> >> > Hi, >> > >> > Is it possible to have an option to triangulate mesh on Alembic export. >> I >> > am trying to import a animation from Blender to Unreal 4.13 and the late >> > ask for tri or quad faces. >> > >> > Also it would be nice to have Z to Y convertion options, as long as >> Unreal >> > rotates the Alembic imports form Blender. >> > >> > Congratulations for the grate job! >> > >> > *Adriano A. Oliveira* >> > ___ >> > Bf-committers mailing list >> > Bf-committers@blender.org >> > https://lists.blender.org/mailman/listinfo/bf-committers >> >> Hi, >> >> Adding an option to triangulate meshes in the exporter wouldn't that >> much of a trouble (though it would have to wait for after the 2.78 >> release), but I have to ask what prevents you from triangulating the >> meshes before exporting? If you've got a lot of objects to triangulate, >> a simple Python script can be written to automate the process. Shall it >> be a destructive operation, or shall it preserve the state of the meshes >> (meaning meshes in Blender are not triangulated, but the exported ones >> are)? >> >> For the axis conversion, Alembic files written from Blender follow the >> Alembic Y-up convention, so I guess this is already what you want? I do >> plan on adding support for more (custom) axis conversions though. >> >> Regards, >> >> Kévin Dietrich. >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> https://lists.blender.org/mailman/listinfo/bf-committers >> > > ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Alembic triangulation
Kévin, I am very interested in the workflow Blender-Unreal through Alembic. The idea is to use Unreal for real time rendering. Alembic in Unreal 4.13 is in preview state, so it will improve a lot. Some findings: 1) Alembic is very usefull to export destruction simulations. I used Cell Fracture to explode a cube and it produces houndreds of n-gons objects. On importing into Unreal, it gives errors. I think this would justify an triangulation option, as in OBJ export. 2) I have some crashes on importing Alembic animated characters into Blender or Unreal that was exported without Flatten Hierarchy. ;) *Adriano A. Oliveira* Professor Adjunto do Curso de Cinema e Audiovisual Universidade Federal do Recôncavo da Bahia (UFRB) Centro de Artes Humanidades e Letras (CAHL) Matrícula: 1673892 (71) 99181-0123 [VIVO] / (71) 99146-8523 [TIM] 2016-08-19 19:10 GMT-03:00 Kévin Dietrich <kevin.dietr...@mailoo.org>: > Le 2016-08-19 23:53, Adriano Oliveira a écrit : > > > Hi, > > > > Is it possible to have an option to triangulate mesh on Alembic export. I > > am trying to import a animation from Blender to Unreal 4.13 and the late > > ask for tri or quad faces. > > > > Also it would be nice to have Z to Y convertion options, as long as > Unreal > > rotates the Alembic imports form Blender. > > > > Congratulations for the grate job! > > > > *Adriano A. Oliveira* > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > https://lists.blender.org/mailman/listinfo/bf-committers > > Hi, > > Adding an option to triangulate meshes in the exporter wouldn't that > much of a trouble (though it would have to wait for after the 2.78 > release), but I have to ask what prevents you from triangulating the > meshes before exporting? If you've got a lot of objects to triangulate, > a simple Python script can be written to automate the process. Shall it > be a destructive operation, or shall it preserve the state of the meshes > (meaning meshes in Blender are not triangulated, but the exported ones > are)? > > For the axis conversion, Alembic files written from Blender follow the > Alembic Y-up convention, so I guess this is already what you want? I do > plan on adding support for more (custom) axis conversions though. > > Regards, > > Kévin Dietrich. > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Alembic triangulation
Hi, Is it possible to have an option to triangulate mesh on Alembic export. I am trying to import a animation from Blender to Unreal 4.13 and the late ask for tri or quad faces. Also it would be nice to have Z to Y convertion options, as long as Unreal rotates the Alembic imports form Blender. Congratulations for the grate job! *Adriano A. Oliveira* ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Any plans on deep compositing?
Good to know it, Jeroen! I think Deep Composing would be a game changer for Blender and Cycles ;) Adriano A. Oliveira ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Any plans on deep compositing?
Hi, Is there any plans on implementing deep compositing render/exporting (Cycles + OpenEXR 2) and in-Blender compositing? Really useful! *Adriano A. Oliveira* ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Multiview frustrum controler reference
Thank you Dalai for the exceptional work in Multiview branch. Stereo images are easy to create in CG, but it is very hard do control how they can be correctly decoded by our brains. The main problem is the relation among human interoccular distance, image resolution, screen size and viewer distance from screen. In short, a 3d film produced for theater release is not good for TV without propper adjustment. So it is very important that Multiview offers in near future a stereo camera rig with a frustrum indicating a safe stereo zone for placing objetcs. This zone would change whenever any os above parameters is changed. We can see the mathematics for this in http://www.noeol.de/s3d/ But I think we could go further and dream with an ideal dinamic stereo frustrum similar to this: https://vimeo.com/57398627 Even if this is not possible right now, it would be very nice if the code allow it to be implemented in near future. ;) Adriano A. Oliveira ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Multiview frustrum controler reference
You are right, Dalay. My intention was not to force any change by now, but to register a sugestion for a future ideal way to controll stereo camera rig. Congratulations again, Adriano A. Oliveira 2014-10-09 11:22 GMT-03:00 Dalai Felinto dfeli...@gmail.com: Hi Adriano, Those high-level controls are desirable. But I tend to favour first implement the core functionality, let users define the ultimate workflow that attend their productions and then we sort what is the unique need of Adriano's pipeline and what is of general interest. The same is true for controlling min-maximum pixel separation in oppose to setting interocular distance and convergence plane. Internally the result is the same so for the initial Multi-View feature-set we provide the low level settings (e.g., interocular and convergence plane) and leave to the users to build customizable solutions for their pipelines. We had addons to provide those even before a robust Multi-View was in place. I'm confident that solutions built on top of the Multi-View/Stereo 3D functionality will be in place in no time. That said, if you have the time to build a proper proposal on how those controllers would fit in the UI and the pipeline I'm all ears. Regards, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014-10-09 11:15 GMT-03:00 Adriano Oliveira adriano.u...@gmail.com: Thank you Dalai for the exceptional work in Multiview branch. Stereo images are easy to create in CG, but it is very hard do control how they can be correctly decoded by our brains. The main problem is the relation among human interoccular distance, image resolution, screen size and viewer distance from screen. In short, a 3d film produced for theater release is not good for TV without propper adjustment. So it is very important that Multiview offers in near future a stereo camera rig with a frustrum indicating a safe stereo zone for placing objetcs. This zone would change whenever any os above parameters is changed. We can see the mathematics for this in http://www.noeol.de/s3d/ But I think we could go further and dream with an ideal dinamic stereo frustrum similar to this: https://vimeo.com/57398627 Even if this is not possible right now, it would be very nice if the code allow it to be implemented in near future. ;) Adriano A. Oliveira ___ 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] 3d LUT in Blender
Ok. It would be nice to have LUT as nodes in compositor. Adriano A. Oliveira 2014-06-17 0:34 GMT-03:00 Troy Sobotka troy.sobo...@gmail.com: On Jun 15, 2014 7:52 AM, Adriano Oliveira adriano.u...@gmail.com wrote: Where and how? Via OpenColorIO's configuration. Feel free to contact me off-list directly if you need assistance. With respect, TJS ___ 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] 3d LUT in Blender
Where and how? Adriano A. Oliveira 2014-06-14 12:36 GMT-03:00 Troy Sobotka troy.sobo...@gmail.com: On Jun 14, 2014 7:01 AM, Adriano Oliveira adriano.u...@gmail.com wrote: Is there suport for 3d LUT in Blender? Yes. With respect, TJS ___ 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] 3d LUT in Blender
Dear friends, Is there suport for 3d LUT in Blender? This would open a lot of possibilities in Color Grading. Adriano A. Oliveira ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Weekly Blender developer meeting minutes - December 29, 2013
Hi Ton, Does Multithreaded depsgraph (merged) means that the old problem of slow updating animation is solved. Like when an character picks up a ball, some times if you stop rendering and try to start rendering again in the middle of the movement, the ball is missplaced... Adriano A. Oliveira 2013/12/29 Ton Roosendaal t...@blender.org Hi all, Holidays time still, it was a short meeting in irc.freenode.net#blendercoders. 1) projects for 2.70 - The targets and planning: http://wiki.blender.org/index.php/Dev:Doc/Projects - Target custom normals is waiting for confirmation, Bastien Montagne can tell more. - Also missing is a list of UI work for 2.70 and later. Brecht van Lommel will check on it, Jonathan Williamson offered help (last week). - Sergey Sharybin thinks the new text alignment in number buttons is not working good. Brecht and Jonathan could check this? 2) Other projects No news, apart from patches to review, lots of bugs to fix, and encouraging OpenCL updates for Mac OS X 10.9.2 (in developer preview) - Cycles now compiles a kernel, but it still doesn't work fully... (slow, render errors). That's it, everyone gets the best wishes for an awesome 2014! Regards, -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer 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
Re: [Bf-committers] Trusted blend files and scripted drivers bug and annoyance
I have already asked for an alternative to the #frame driver for rendering animation in Cycles. It is realy not a good aproach anymore due to new security policies. Seed should always vary per frame. Static seed is an exception, it is only usefull in very rare situations when you need to compare renders. #frame is not obvious for most users, and with new policies it leeds to mistakes, like Daniel points out. Adriano A. Oliveira 2013/8/9 Daniel Salazar - 3Developer.com zan...@gmail.com I'm also having problems with students in the simple case of a #frame driver in cycles seed. I can never be sure they all have the enable python setting on in all the computers they use even if I tell them to enable it, this stuff is just never guaranteed in the real world because people forget this stuff. Of course renders turn out useless because of fixed noise. Daniel Salazar patazstudio.com On Fri, Aug 9, 2013 at 2:30 PM, Jace Priester jacepries...@threespaceimaging.com wrote: I expressed a lot of disagreement with the Trusted feature when there was talk about implementing it, and I'm here to voice a complaint again now that it has become a problem. I have created an animation using a scripted expression driver and that driver's value evaluates to zero. I did not notice the Continue Untrusted button appear at the top right. I've spent hours trying to figure out why scripted drivers don't work, only to save and reload and then be prompted to Reload Trusted. This has been a gigantic waste of my time and is precisely the reason I did not want this trusted junk in the first place. I am aware of the command line options to disable it, but I never expected to have to do that. I understand the Reload Trusted prompt when opening a file. However, when I create a brand new driver and enter the expression myself it should work immediately. In any case, it damn sure should not show a value of zero without a notice right next to it that it skipped evaluation entirely. As-is, this is very misleading and indicates that the expression did in fact resolve to a value of zero. -- -- Jace Priester Threespace Imaging jacepries...@threespaceimaging.com 559-284-0904 -- ___ 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] Game Development with Blender - bge book release 20/6/13
Congratulations, Dalai!!! * espero que não seja só por 0,20 centavos... :D Adriano 2013/6/19 Erwin Coumans erwin.coum...@gmail.com I pre-ordered it, congratulations with the book! On 19 June 2013 12:13, Dalai Felinto dfeli...@gmail.com wrote: Dear fellow Blender developers and artists, After a long waiting period, Game Development with Blender book Mike Pan and I wrote together will be released this Thursday, the 20th. To read more about the book, download a sample file and find links to buy it online, visit: http://www.dalaifelinto.com/?p=930 We would like to express our gratitude towards everyone behind Blender as awesome as it is. Thank you all! :) And don't wait long, the book release is tomorrow, and Amazon 41% discount pre-sale campaign may end up any soon: http://www.amazon.com/dp/1435456629 Best regards, Dalai and Mike -- blendernetwork.org/member/dalai-felinto www.dalaifelinto.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Multiview branch feedback
Hi Brecht, But can you explain to me specifically why that is better than the workflow used in the branch? Because it is more simple and better fits in actual Blender logic. It is also the way everey other composite sistem works, as far as I know. But why? How is this different from the RenderLayer/RenderPass distinction we have already? The current SELECT VIEW approach in Image Editor is leading to limitations and changing too much in Blender UI and Node Editor. • Select View is not necessary because we already have Select Pass and L/R views are simply new kind of passes. • Select View 3-D offers a fancy fast-composition that is independent from Node Editor, so it turns Image Editor inconsistent with composition. • Implementing Select View is a danger, because it changes a lot in Node Editor output logic, without offering as much. • Treating L/R as passes is just enough. We add new possibilities and don't chage a lot what is already working. • Obtaining Image Editor stereo outputs through composition nodes is just enough and safer. • To keep node editor compatible with new EXR capabilities we just need a Nuke like merge channel node, so we can re-insert decomposed layers and output them to a single file. This is useful beyond stereo. • STEREO PREVIEW option in 3D View is ok. We don't need stereo options in user preferences, as long as automated preview would only affect 3D View, and Node Editor affects Image Editor. Let's just not add to Node Editor/Image Editor things that leads to different and untested workflows that we don't miss. This is a very nice discussion! :D Adriano 2013/6/17 Brecht Van Lommel brechtvanlom...@pandora.be Hi Adriano, On Mon, Jun 17, 2013 at 6:33 AM, Adriano Oliveira adriano.u...@gmail.com wrote: Schneider's approach relies in Composite for obtain stereo results. This is perfect for my outputs because it offers me control and uses what is right there in Blender already. My stereo outputs are: (1) Side by site or over under composites to preview in my 3d TV and web delivering; (2) separated L/R files for blu-ray and DCP authoring. (2) works in the branch I think. (1) does not at the moment but would fit as a file save option. Nevertheless, even with a good camera, sometimes we need to “lie” to get good results. For example, to certain shot to work in stereo I may need to control convergence of objects and background separately. Imagine a space scene: camera close to an alien pilot in the cockpit, a second spaceship 10 meters way, and the star field in the background… No real camera rig would get this right in one shot. We better control convergence plane by plane in composite. Other example: take a real footage stereo shot, track it and try to place 3d elements over it. Having access to R/L views from Render Layers is essential for a good match. Ok, as far as I can tell all that fits in the current design. When producing a stereo film, I miss these things: 1. A real stereo camera (or a good L/C/R camera rig) with numeric and visual convergence/safe areas controls. Schneider's add-on is a good starting point. 2. OpenGL stereo preview of viewport, based on camera rig convergence. (I think corrected color anaglyph or b/w anaglyph is the most useful here). 3. Easy way to render L/R views with Cycles speed optimizations: not calculating geometry twice, for instance. 4. Easy way to access L/R views from Render Layers in Node Editor for me to compose whatever I want. The Stereo Node that I proposed is not essential, but something user-friendly as a ubbershader. 5. EXR support for L/R views archiving, no doubt. 2,3,5 are implemented, 1,4 are planned I think. See here for the todo list: https://github.com/dfelinto/blender/issues 1. Separate stereo preview in Blender's viewport (OpenGL / 3D View) from render output in Image Editor. We don’t need automated multiview in Image Editor, because the way it is done just masses with node editor/composite output. 2. Let me do my stereo composites in node editor. If you want to help newcomers, create a Stereo Node, as I have proposed. 3. I need to access views from a Render Layer the same way I have access to render passes. 4. Let us use the great work Dalai is doing with EXR 2 and go further by adding ways to merge and insert new layers in composite output. This way we could work views from Render Layers separately and recompose them to save in EXR. The same functionalities would allow me to add/merge other new layers (corrected mattes for instance) to composite output, so I can save as EXR as well. This would be helpful for communicating with other software, or among different teams. As far as I can tell, this all boils down to a different workflow than the branch has now. Instead of running the compositor once for each view, you want the compositor to run once and manually make a setup that applies nodes to both
Re: [Bf-committers] Multiview branch feedback
Brecht, I think I wrote enogh to explain my analisys. It is a lot more than simply my way is better. Let's wait for other users that are rely working with stereo to publish their feedbacks too. I rest my case for now ;) Adriano 2013/6/17 Brecht Van Lommel brechtvanlom...@pandora.be Hi Adriano, I can't do much with this answer, to me this reads it's better because it's better. It doesn't explain how anything that is possible in your workflow will not be possible now, or how your workflow is simpler. I'd like to understand it but as far as I can tell you are just reiterating how you want it to work and not why it should work that way? To me this is similar to the color management and premultiplied/straight alpha discussions, and to the way full sample AA works for example. Some people will say, just give me the nodes to do all the conversions and I'll set it up myself. That's on way to do it and we can support that. If you want to create a separate scene for compositing and composite the L/R parts in one nodes setup, you should be able to do that. But we can provide a higher level workflow too that makes things easier for most users. And for that workflow I think it's important to have a good separation between what you do in the compositing nodes and the particular stereo method that is used for display and file saving. Thanks, Brecht. On Mon, Jun 17, 2013 at 2:51 PM, Adriano Oliveira adriano.u...@gmail.com wrote: Hi Brecht, But can you explain to me specifically why that is better than the workflow used in the branch? Because it is more simple and better fits in actual Blender logic. It is also the way everey other composite sistem works, as far as I know. But why? How is this different from the RenderLayer/RenderPass distinction we have already? The current SELECT VIEW approach in Image Editor is leading to limitations and changing too much in Blender UI and Node Editor. • Select View is not necessary because we already have Select Pass and L/R views are simply new kind of passes. • Select View 3-D offers a fancy fast-composition that is independent from Node Editor, so it turns Image Editor inconsistent with composition. • Implementing Select View is a danger, because it changes a lot in Node Editor output logic, without offering as much. • Treating L/R as passes is just enough. We add new possibilities and don't chage a lot what is already working. • Obtaining Image Editor stereo outputs through composition nodes is just enough and safer. • To keep node editor compatible with new EXR capabilities we just need a Nuke like merge channel node, so we can re-insert decomposed layers and output them to a single file. This is useful beyond stereo. • STEREO PREVIEW option in 3D View is ok. We don't need stereo options in user preferences, as long as automated preview would only affect 3D View, and Node Editor affects Image Editor. Let's just not add to Node Editor/Image Editor things that leads to different and untested workflows that we don't miss. This is a very nice discussion! :D Adriano ___ 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] Multi-view branch UI proposal
Hi Brecht and Dalai, Here goes a visual proposal: https://dl.dropboxusercontent.com/u/33950890/multiview%20UI.pdf Adriano ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Multiview branch feedback
I haven't used this blender multiview branch and have only skimmed over this thread briefly, but it seems to me that it works in a similar way to nuke. In nuke, you can set up as many views as you like, and by default, nodes will apply the same processing to the multiple views in an input stream. Yes. It's possible to split off individual views into individual data streams, process them independently, and then join them back into the one stream if you like, Only for saved files. I want this for Render Layers also. and it's also possible to split individual parameters on nodes so you can apply different parameter values to different views. In general though, you're passing all views down your comp network together as a single data stream. No, and it is exactly what I am proposing to be implemented. There are also additional nodes that specifically deal with multiview inputs, for example nodes to change convergence. Not at the moment, but is part of what I am requesting. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Multi-view branch UI proposal
Ok for Select View logic as long as it is a EXR recomandation. Here goes a 1.2 Update, with other small fixes. https://dl.dropboxusercontent.com/u/33950890/multiview%20UI.pdf Adriano A. Oliveira Livro: http://goo.gl/WtcNX Lattes: http://lattes.cnpq.br/8343393957854863 Blog Anodinidades: http://anodinidades.wordpress.com/ Produções audiovisuais: *http://vimeo.com/anodinidades/videos* http://vimeo.com/anodinidades/videosFotografia: http://www.flickr.com/photos/adriano-ol/ Facebook: http://www.facebook.com/adriano.ol Twitter: http://twitter.com/anodinidades 2013/6/17 Dalai Felinto dfeli...@gmail.com Some comments: 1) You are mixing up display modes (side-by-side, anaglyph, ..) with view selector (left, right, ...). That's a bad design in my opinion. 2) The view modes (side-by-side, ...) have to be applied for the whole screen. Right now you choice the 3D stereo display mode in user preference because your 3D display is part of your workstation setup. If you have a 3D display that take side-by-side you will use side-by side with it all the time. 2.1) That said, I think (for the sake of flexibility) it's reasonable to have 3D stereo mode per window. That should be set in the Info Editor header though, not in viewport/render panels. 3) Arguably, the fact [that] there are multiple views of a pass in an EXR is only as interesting to the artists as that it contains R,G,B,A channels. (Peter Hillman, OpenEXR dev) To show the Combined.left and Combined.right is not aligned with that. And I can't see why you would want that (it makes the UI clumsy) 4) That said, to have an option to select the view you want to render from a given RenderLayer node MAY work. The big problem here is that if you want to compose multiple views at the same time you need to have one scene dictating how many views (and which views) we are rendering. Right now we are doing something like: for view in render.views: compose (view.name) I think the benefits of being able to compose multiview natively still beats the potential advantages of rendering individual views of a RenderLayer. 5) The option of selecting the multiview camera to use in the viewport is not a bad idea. In a way it's similar with what we have for the Image Editor. 6) The option of selecting the views in the render panel may be interesting. But I will restrict that to left, right, view1, view2, ..., All. Again (see 1) no EXR, Anaglyph, ... here. 6.1) We could later implement an easy way to output side-by-side, anaglyph, ... My original idea (nowhere implemented) in the Image Editor you should even be able to select how to save the stereo image (single view, all views [EXR], stereo [anaglyph, side-by-syde, ...]). I'm really busy so I'm taking slow in the emails. I was actually planning to reply to your other proposal email only after I was done with the review changes proposed by Brecht. But feedback like yours (specially when concise and well structured) is really welcome. Cheers, Dalai Why not only change the view mode (side-by-side, ...) in the user p você está misturando forma de visualizar (side-by-side, ...) com que view ver (left, right, ...) e o image editor precisa de 3D tanto quanto o viewport Que mais, acho que mostrar os passes 1 a 1 não faz sentido (acho que o brecht já tinha argumentado a respeito) Nas palavras das especificações do EXR: para o artista, o fato de que um passe tem multiplas views é tão (ir)relevante quanto o fato de que tem R, G, B ou seja, a view faz parte do pass Agora, acho interessante a idéia de ter um seletor de view no Render panel e na viewport -- blendernetwork.org/member/dalai-felinto www.dalaifelinto.com 2013/6/17 Adriano Oliveira adriano.u...@gmail.com: Hi Brecht and Dalai, Here goes a visual proposal: https://dl.dropboxusercontent.com/u/33950890/multiview%20UI.pdf Adriano ___ 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] Multiview branch feedback
So...? Adriano 2013/6/11 Adriano Oliveira adriano.u...@gmail.com Hi Dalai, I would like to contribute with some feedbacks to your branch from a user’s point of view. First of all, congratulations for the initiative and for the outcome so far. It is a remarkable achievement, no doubt. *What I like the most:* - Now it is possible to render Left and Right views from two cameras in the same scene! - These two views are treated as layers or meta layers and can be saved as channels in EXR 2.0! - It is possible to preview the two views as composites (anaglyphs, side by side…) in 3d viewport, what is great for animators. In my humble opinion, the problems are related to the fact that the very implementations that allow stereo preview in 3d viewport are leading to lack of control in Image Editor and Composite. To be more specific: *What I am not sure of and proposals:* - The same approach that allows previewing stereoscopy in 3d viewport is not as useful in Image Editor (render outcome) and Composite. I think it is better that Image Editor only shows stereo images as long as they have been composed in Composite as such. - For that reason, I would remove the “3-D” option in “Select View”. Better: In Image Editor I would remove this new “Select View”, for it leads to confusion when dealing with Composite outputs. Even though it may seams repetitive, it is more correct and informative to add the views ids in the old “Select Pass”, by adding suffixes: Composite.Left; Composite.Right; Z.Left; Z.Right… These suffixes should be added whenever the user activates L or R views in Render Views. - In consequence, stereo automated previews shoud not be a UI or Blender Window general option in Preferences, but an option only related to a single 3d Viewport, in the very Viewport. - In Composite, Render Layers nodes are lacking a switch for choosing Left or Right, like Image nodes already have. Both should offer Left and Right switches, and… - Render Layers and Image nodes should NOT offer a “3-D” switchfor it is not useful in Composite and leads to confusion. 3-D is not a channel within Render Layer or Image, it’s just a fast composition option of two layers, based on generic parameters. - It is more logical to get stereo outcome composing Left and Right in a new “Stereo Node”, that would offer: 02 inputs (channels from toggled L / R Render Layers or Image nodes), 01 selector with presented stereo modes (side by side, over under…); 01 input numerical parameter for convergence correction; 01 composed stereo image output. Very important: this Stereo Node is only for final composed output files (PNG, TIFF) and Movies. We need to implement another new node for “optional” re-merging the decomposed L/R views for output as channels in Composite (for editing stereo in Sequecer, for instance) or as channels/layers in EXR 2.0 files. This logic of decomposing layers to better work with them, and then merging them together later with a new “Merge Channel” or “Merge Pass” node is similar to what Nuke already does. This only would be (stereo aside) a great implementation in Blender Composite, and must in EXR 2.0 logic. I hope to help. Adriano A. Oliveira ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Multiview branch feedback
Further UI feedbacks: - Change any reference to 3-D to Stereo or Multiview. - I would prefere not create a new Render Views tab in Properties pannel, as long as it's not fundamental for most users. It's functions may better be relocated to recently created Render Passes tab. - [Not shure] I would create a new STEREO PREVIEW panel, based on existing 3D VIEW. This panel should offer the options that are now hided in User Prefereces, so I can dinamicly chose Anagliph, Side by Site etc. - As I have explanad below, Image Editor should not offer any 3-D switch. Image Editor should show stereo composites as long as they are expresed composed in Composite. Adriano A. Oliveira Livro: http://goo.gl/WtcNX Lattes: http://lattes.cnpq.br/8343393957854863 Blog Anodinidades: http://anodinidades.wordpress.com/ Produções audiovisuais: *http://vimeo.com/anodinidades/videos* http://vimeo.com/anodinidades/videosFotografia: http://www.flickr.com/photos/adriano-ol/ Facebook: http://www.facebook.com/adriano.ol Twitter: http://twitter.com/anodinidades 2013/6/11 Adriano Oliveira adriano.u...@gmail.com Hi Dalai, I would like to contribute with some feedbacks to your branch from a user’s point of view. First of all, congratulations for the initiative and for the outcome so far. It is a remarkable achievement, no doubt. *What I like the most:* - Now it is possible to render Left and Right views from two cameras in the same scene! - These two views are treated as layers or meta layers and can be saved as channels in EXR 2.0! - It is possible to preview the two views as composites (anaglyphs, side by side…) in 3d viewport, what is great for animators. In my humble opinion, the problems are related to the fact that the very implementations that allow stereo preview in 3d viewport are leading to lack of control in Image Editor and Composite. To be more specific: *What I am not sure of and proposals:* - The same approach that allows previewing stereoscopy in 3d viewport is not as useful in Image Editor (render outcome) and Composite. I think it is better that Image Editor only shows stereo images as long as they have been composed in Composite as such. - For that reason, I would remove the “3-D” option in “Select View”. Better: In Image Editor I would remove this new “Select View”, for it leads to confusion when dealing with Composite outputs. Even though it may seams repetitive, it is more correct and informative to add the views ids in the old “Select Pass”, by adding suffixes: Composite.Left; Composite.Right; Z.Left; Z.Right… These suffixes should be added whenever the user activates L or R views in Render Views. - In consequence, stereo automated previews shoud not be a UI or Blender Window general option in Preferences, but an option only related to a single 3d Viewport, in the very Viewport. - In Composite, Render Layers nodes are lacking a switch for choosing Left or Right, like Image nodes already have. Both should offer Left and Right switches, and… - Render Layers and Image nodes should NOT offer a “3-D” switchfor it is not useful in Composite and leads to confusion. 3-D is not a channel within Render Layer or Image, it’s just a fast composition option of two layers, based on generic parameters. - It is more logical to get stereo outcome composing Left and Right in a new “Stereo Node”, that would offer: 02 inputs (channels from toggled L / R Render Layers or Image nodes), 01 selector with presented stereo modes (side by side, over under…); 01 input numerical parameter for convergence correction; 01 composed stereo image output. Very important: this Stereo Node is only for final composed output files (PNG, TIFF) and Movies. We need to implement another new node for “optional” re-merging the decomposed L/R views for output as channels in Composite (for editing stereo in Sequecer, for instance) or as channels/layers in EXR 2.0 files. This logic of decomposing layers to better work with them, and then merging them together later with a new “Merge Channel” or “Merge Pass” node is similar to what Nuke already does. This only would be (stereo aside) a great implementation in Blender Composite, and must in EXR 2.0 logic. I hope to help. Adriano A. Oliveira ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Multiview branch feedback
. In addition, if we implement a node do add/merge new layers in the composition, we will need to see them listed in Image Editor's SELECT PASS. Small points: 6. Let’s change any reference to 3-D to Stereo or Multiview. 7. I would prefer not create a new Render Views tab in Properties panel. It's functions may better be relocated to recently created Render Passes tab. Best regards, Adriano A. Oliveira 2013/6/16 Brecht Van Lommel brechtvanlom...@pandora.be Hi, Thanks for the feedback. Dalai might have a different opinion but here is my take on this design. On Wed, Jun 12, 2013 at 4:22 AM, Adriano Oliveira adriano.u...@gmail.com wrote: In my humble opinion, the problems are related to the fact that the very implementations that allow stereo preview in 3d viewport are leading to lack of control in Image Editor and Composite. To be more specific: The current workflow is to composite the left view and right view using the same node setup. Being able to run compositing for stereo renders without needing special nodes is very valuable I think. It makes it easy to switch stereo on, and switch it back off as well without having to fiddle with nodes. Of course there may be more advanced scenarios where you want special nodes to somehow use both left and right views in a single node setup, but I don't see why you would make that a requirement. Can you be more specific about why you think it has to work this way, like specific node operations that you need to be able to do that are not possible now? *What I am not sure of and proposals:* - The same approach that allows previewing stereoscopy in 3d viewport is not as useful in Image Editor (render outcome) and Composite. I think it is better that Image Editor only shows stereo images as long as they have been composed in Composite as such. Why is this better? Isn't it useful to be able to enable stereo, press render, and get a stereo image immediately? - For that reason, I would remove the “3-D” option in “Select View”. Better: In Image Editor I would remove this new “Select View”, for it leads to confusion when dealing with Composite outputs. Even though it may seams repetitive, it is more correct and informative to add the views ids in the old “Select Pass”, by adding suffixes: Composite.Left; Composite.Right; Z.Left; Z.Right… These suffixes should be added whenever the user activates L or R views in Render Views. I'm not sure why this is more correct, I don't see why representing these as passes instead of views helps? The only reason OpenEXR stores them this way is to keep the file format compatible, but for user interfaces it makes sense to represent things more organized and not at this low level. We could have done the same for RenderLayers and RenderPasses, putting them all together in one big list. They full names in OpenEXR files are RenderLayer.Z.Left, etc. But this does not make for a better UI in my opinion. - In consequence, stereo automated previews shoud not be a UI or Blender Window general option in Preferences, but an option only related to a single 3d Viewport, in the very Viewport. I can see how it would be useful to have control over this at the viewport level. But even if we have that a default stereo viewing method in the user preferences seems like a good idea to me? It depends on the monitor and operating system configuration so it belongs in user preferences I think. - In Composite, Render Layers nodes are lacking a switch for choosing Left or Right, like Image nodes already have. Both should offer Left and Right switches, and… I think there were some plans to allow you to use a specific view in the Render Layer instead of automatically left/right but I'm not sure what the status of that is. You would get the options Auto / Left / Right and then you can choose which view to use. If it's there for images I guess it will be there soon for Render Layer nodes too. - Render Layers and Image nodes should NOT offer a “3-D” switchfor it is not useful in Composite and leads to confusion. 3-D is not a channel within Render Layer or Image, it’s just a fast composition option of two layers, based on generic parameters. Not sure why this is a problem. These settings in the header are just a way to specify what you want to view. So why not specify there that you want to view Left, Right or 3D? Is it because it might confusing users into thinking this data will be saved in files? I can see that, maybe the UI should be designed to make that more clear. The option to view 3D should be there somewhere though. - It is more logical to get stereo outcome composing Left and Right in a new “Stereo Node”, that would offer: 02 inputs (channels from toggled L / R Render Layers or Image nodes), 01 selector with presented stereo modes (side by side, over under…); 01 input numerical parameter
[Bf-committers] Multiview branch feedback
Hi Dalai, I would like to contribute with some feedbacks to your branch from a user’s point of view. First of all, congratulations for the initiative and for the outcome so far. It is a remarkable achievement, no doubt. *What I like the most:* - Now it is possible to render Left and Right views from two cameras in the same scene! - These two views are treated as layers or meta layers and can be saved as channels in EXR 2.0! - It is possible to preview the two views as composites (anaglyphs, side by side…) in 3d viewport, what is great for animators. In my humble opinion, the problems are related to the fact that the very implementations that allow stereo preview in 3d viewport are leading to lack of control in Image Editor and Composite. To be more specific: *What I am not sure of and proposals:* - The same approach that allows previewing stereoscopy in 3d viewport is not as useful in Image Editor (render outcome) and Composite. I think it is better that Image Editor only shows stereo images as long as they have been composed in Composite as such. - For that reason, I would remove the “3-D” option in “Select View”. Better: In Image Editor I would remove this new “Select View”, for it leads to confusion when dealing with Composite outputs. Even though it may seams repetitive, it is more correct and informative to add the views ids in the old “Select Pass”, by adding suffixes: Composite.Left; Composite.Right; Z.Left; Z.Right… These suffixes should be added whenever the user activates L or R views in Render Views. - In consequence, stereo automated previews shoud not be a UI or Blender Window general option in Preferences, but an option only related to a single 3d Viewport, in the very Viewport. - In Composite, Render Layers nodes are lacking a switch for choosing Left or Right, like Image nodes already have. Both should offer Left and Right switches, and… - Render Layers and Image nodes should NOT offer a “3-D” switchfor it is not useful in Composite and leads to confusion. 3-D is not a channel within Render Layer or Image, it’s just a fast composition option of two layers, based on generic parameters. - It is more logical to get stereo outcome composing Left and Right in a new “Stereo Node”, that would offer: 02 inputs (channels from toggled L / R Render Layers or Image nodes), 01 selector with presented stereo modes (side by side, over under…); 01 input numerical parameter for convergence correction; 01 composed stereo image output. Very important: this Stereo Node is only for final composed output files (PNG, TIFF) and Movies. We need to implement another new node for “optional” re-merging the decomposed L/R views for output as channels in Composite (for editing stereo in Sequecer, for instance) or as channels/layers in EXR 2.0 files. This logic of decomposing layers to better work with them, and then merging them together later with a new “Merge Channel” or “Merge Pass” node is similar to what Nuke already does. This only would be (stereo aside) a great implementation in Blender Composite, and must in EXR 2.0 logic. I hope to help. Adriano A. Oliveira ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Stereoscopy Implementation Proposal
Hi Dalai, My intention in showing off is just state my interest in stereoscopy in Blender. The boat is not CC, but it is ok to use on tests, as long as you don't share the model. I can send it to you as soon as possible. Producing stereoscopic renders are realy easy in any 3d software, but controling to get good takes is very hard and few softwares have good free tools already implemented. My exemple test is no good: the saparetion is too intense and it causes problems to resolve in perception. I have a better render now, with convergence corrected in After Effects, that has a nice and easy pluging to deal with two cameras renders. I have done three vertions: anaglyph, optimized analglyph [see link below], and side by side. This last one to wach in .mp4 on my LG passive 3D TV, via USB flashdrive (no need of a external player). The conclusion: anaglyph is useless but for preview. 3D Tvs/monitors are the way to go. http://www.svoigt.net/index.php/tutorials/22-stereoscopic-3d/29-optimized-anaglyph I like very much the development of your proposal. PS: Sebastian Schneider's addon is not 100% funtional with latests builds, since render layers got to its own place in UI. ;) Adriano A. Oliveira Livro: http://goo.gl/WtcNX Lattes: http://lattes.cnpq.br/8343393957854863 Blog CG Total: http://cgtotal.net Blog Anodinidades: http://anodinidades.wordpress.com/ Produções audiovisuais: *http://vimeo.com/anodinidades/videos* http://vimeo.com/anodinidades/videosFotografia: http://www.flickr.com/photos/adriano-ol/ Facebook: http://www.facebook.com/adriano.ol Twitter: http://twitter.com/anodinidades 2013/4/15 Dalai Felinto dfeli...@gmail.com Hi Adriano, not sure what to get from the test. I guess this means you are able to work with Blender as it, so there is no need for a more robust stereo support? ;) Now seriously, is this file cc? If so can you send it over? (or at least one exr per eye?). It will help with the tests at some point. -- A quick update: I'm done with the read/write routines for multiview. The current code is on: http://github.com/dfelinto/blender/tree/multiview So far the implementation is by considering the views just as another pass (one of Ton's ideas). For example: RenderLayer.Combined.left.R layer: RenderLayer pass: Combined.left channel: R Note also that Combined.left is a pass and Combined.right would be another pass. My next goal is to tackle render. For that I'll add views to the scene, which are a camera and a name. The plan is as follow: 1) read multiview exr [done] 2) see multiview in UV/image editor as mono [done] 3) write multiview exr [done] 4) render in multiview 5) compo in multiview 6) see multiview in UV/image editor as stereo 7) see viewport preview 8) ? -- Dalai blendernetwork.org/member/dalai-felinto www.dalaifelinto.com 2013/4/14 Adriano Oliveira adriano.u...@gmail.com: A new test: http://youtu.be/LhbkgRXBVJU Adriano A. Oliveira ___ 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] Stereoscopy Implementation Proposal
A new test: http://youtu.be/LhbkgRXBVJU Adriano A. Oliveira ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Stereoscopy Implementation Proposal
Sugestion: It would be nice if we can manage to set an existing camera to be left or right, and don't me moved at all when we setup planes in stereoscopy. This would be very usefull to convert old project to 3d, so we can keep old renders as left or right and just render one new camera. If the addon turns old camera into center, this is not possible and we have to render every thing allover again. -- View this message in context: http://blender.45788.n6.nabble.com/Stereoscopy-Implementation-Proposal-tp106106p106425.html Sent from the Bf-committers mailing list archive at Nabble.com. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Stereoscopy Implementation Proposal
Loved to know about this proposal, Dalai. I have been studing stereoscopy lately. I use this addon a lot: http://www.noeol.de/s3d/ I sugest the funcionalities in this Plugin for 3dsmax: http://davidshelton.de/blog/?p=354 hope to contribute more soon. Adriano -- View this message in context: http://blender.45788.n6.nabble.com/Stereoscopy-Implementation-Proposal-tp106106p106332.html Sent from the Bf-committers mailing list archive at Nabble.com. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
