[Bf-committers] Trackball rotation acts diferently?
Is it just me or trackball rotation acts differently then in 2.4x? I'm having difficulties with retaining center of rotation without use of 3D cursor. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Trackball rotation acts diferently?
since we are talking about it anyways... i'd just like to mention that i really prefer how Wings3D navigates the view: middle click enter rotation mode, then left click sets, right click cancels. It is more ergonomic than blender2.4x and 2.5 - having to hold down the middle mouse button is stressful on the hand. my 2cents, -brett On Mon, Nov 30, 2009 at 4:51 PM, Damir Prebeg wrote: > Is it just me or trackball rotation acts differently then in 2.4x? I'm > having difficulties with retaining center of rotation without use of 3D > cursor. > > > > ___ > 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] Shading System Proposals
Hi, I've written down a proposal for the shading system refactor: http://wiki.blender.org/index.php/BlenderDev/ShadingSystem It's quite technical. This page has more details on some of the things mentioned: http://wiki.blender.org/index.php/User:Brecht/RenderIdeas Matt has also been investigating this, there's some overlap in topics but he has much more detail on various topics: http://wiki.blender.org/index.php/User:Broken/ShadingSystemDesignIdeas http://wiki.blender.org/index.php/User:Broken/RendererResearch http://wiki.blender.org/index.php/User:Broken/ShadingSystemScratchpad http://wiki.blender.org/index.php/User:Broken/BreakingRenderCompatibility So, feedback is welcome, in particular on the design and issues listed at the end of the page. As you can see we are looking at this from a production rendering and physically based rendering point of view, trying to find a nice synthesis of both. Brecht. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Shading System Proposals
Hi, To get some discussion started, here's two things I'm still unsure about, extracting a BXDF from node trees and the future role of the texture stack. > Matt has also been investigating this, there's some overlap in topics > but he has much more detail on various topics: > http://wiki.blender.org/index.php/User:Broken/ShadingSystemDesignIdeas > http://wiki.blender.org/index.php/User:Broken/RendererResearch Matt proposes a Sample_F output here but it's not entirely clear to me how this works, I also couldn't understand from the Houdini documentation for example if their BSDF F value is just a vector/scalar value or also contains information on how to sample it. I can think of a few ways to do this using a node tree, doing the computation F by evaluating nodes with some entirely or partially excluded, and doing sample distribution by picking randomly from distributions provided by nodes that contain a BXDF. Another possibility would be to pass a long a BXDF type through nodes, then for example a mix node could create a new BXDF that can do more clever importance sampling. Neither seems particularly elegant or transparent to the user to me, but I can't think of good alternatives at the moment. The texture stack is obviously limited in what it can texture. Nodes provide a solution here, but the texture stack is still convenient. So what is the role of the texture stack, do we try to fix it, and if so do we make it more flexible like allowing to texture nearly everything, or maybe we just leave it as is mostly and do a few small tweaks? Brecht. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Meeting summary
On Sun, Nov 29, 2009 at 7:39 AM, Tom M wrote: > 3) other merges (BMesh, NURBS) need to be evaluated for feasibility yet The NURBS branch is stable and mature enough to offer a replacement for the existing NURBS tools. I'm not sure if it makes more sense to commit this first without adding much new functionality, or to wait until there are many new/improved tools. 2.5 is missing a lot of the old tools, so I'm planning to revisit a lot of those. I will have a significant chunk of time to work on this at the beginning of 2010. I'm happy to keep working on my branch, but if it's needed I'm happy to commit the 'NURBS engine' to trunk and work from that instead. -Emmanuel ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Meeting summary
re: merging nurbs. Its great to hear its ready to merge (or very close), last I looked into the nurbs branch It was so hard to tell what was supposed to be working. Id recommend... - getting all the old tools in 2.5 first, didn't think there was that much left to do, (take a day or 2?), - review the branch - I could review some areas I'm familiar with, anyone else able to help with review?. - merge when we can validate the branch works as well as trunk - continue development in trunk (new features/tools etc). On Mon, Nov 30, 2009 at 8:07 PM, Emmanuel Stone wrote: > On Sun, Nov 29, 2009 at 7:39 AM, Tom M wrote: >> 3) other merges (BMesh, NURBS) need to be evaluated for feasibility yet > > The NURBS branch is stable and mature enough to offer a replacement > for the existing NURBS tools. I'm not sure if it makes more sense to > commit this first without adding much new functionality, or to wait > until there are many new/improved tools. 2.5 is missing a lot of the > old tools, so I'm planning to revisit a lot of those. > > I will have a significant chunk of time to work on this at the > beginning of 2010. I'm happy to keep working on my branch, but if it's > needed I'm happy to commit the 'NURBS engine' to trunk and work from > that instead. > > -Emmanuel > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Vertex Paint Patch
I've written a patch to make the vertex paint toolbar a bit more like weight paint, I've also added a draw function to the Vertex Dirt script. Get the patch here: http://www.pasteall.org/9537/diff Cheers, Keith. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Fixed bug of Verlet integrator (Farsthary)
Hi all :) Thanks to mcmacsurfer feedback I could spot the bug in the verlet integrator and the solution was quite simple also, I was using the pa->prev_state.co but aparently that state is modifyed/used in several parts of the particle pippeline so changes in it could lead to strange particle behaviours, instead return to my original proposal of using a temporal variable that store the initial particle position at the beginning of the function apply_particle_forces(). Now everything works as should do. Thanks for the feedback Farsthary Here´s the solution: http://www.pasteall.org/9538/diff in function apply_particle_forces() -- float force[3],impulse[3],dx[4][3],dv[4][3],diff[3]; ++ float force[3],impulse[3],dx[4][3],dv[4][3],diff[3],tempos[3]; ... /* maintain angular velocity */ VECCOPY(pa->state.ave,pa->prev_state.ave); ++ VECCOPY(tempos,pa->state.co); ... case PART_INT_VERLET: VECADDFAC(pa->state.vel,pa->state.vel,force,dtime); VecMulf(pa->state.vel,dtime); VecAddf(pa->state.co,pa->state.co,pa->state.vel); --VecSubf(diff,pa->state.co,pa->prev_state.co); ++VecSubf(diff,pa->state.co,tempos); VecMulf(diff,1.f/dtime); VECCOPY(pa->state.vel,diff); break; ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Shading System Proposals
On 01/12/2009, at 2:05 AM, Brecht Van Lommel wrote: > Hi, > > To get some discussion started, here's two things I'm still unsure > about, extracting a BXDF from node trees and the future role of the > texture stack. > >> Matt has also been investigating this, there's some overlap in topics >> but he has much more detail on various topics: >> http://wiki.blender.org/index.php/User:Broken/ >> ShadingSystemDesignIdeas >> http://wiki.blender.org/index.php/User:Broken/RendererResearch > > Matt proposes a Sample_F output here but it's not entirely clear to me > how this works, I also couldn't understand from the Houdini > documentation for example if their BSDF F value is just a > vector/scalar value or also contains information on how to sample it. I've done some research on this, and I think I have a fair idea of what's going on in there. I actually suspect it's quite similar to what I was toying around with before [1]. Rather than containing merely values, the brdf type probably contains some function pointers to pre-made functions (i.e. lambert distribution, phong distribution, etc), since that's really the only way to represent a Scattering Distribution _Function_. It also contains some other flags to say what kind of scattering it can represent (diffuse, glossy, specular, emission) etc, and probably some custom data to represent bsdf parameters (like a glossiness slider). I'm guessing this via a few VEX functions: * sample_bsdf() [2] that takes a bsdf, 2d random samples, and shading geometry as input, and returns an outgoing vector - eg. for lambert a cosine weighted vector in hemisphere, and * eval_bsdf() [3] which takes a bsdf and shading geometry input and returns a colour (proportion of light that's reflected) - eg for lambert, L.N . These above functions would basically just execute the bsdf callbacks with the input information. As for how it mixes bsdfs, some ideas are either it somehow dynamically generates new distribution function callbacks that represent multiple combined distributions (which i seriously doubt) or it uses some kind of internal layering/stacking system where it keeps track of what BxDFs make up the entire BSDF, and with what weights. > I can think of a few ways to do this using a node tree, doing the > computation F by evaluating nodes with some entirely or partially > excluded, and doing sample distribution by picking randomly from > distributions provided by nodes that contain a BXDF. You don't want to do it randomly, it should be weighted it based on layering - a probability per BxDF component. So for example if you're shading a glass shader with perfect specular BRDF and specular BTDF, blended via fresnel, then if the incoming ray is at glancing angles, there's much higher probability (fresnel function) of picking an outgoing vector based on the BRDF, not the BTDF. > Another > possibility would be to pass a long a BXDF type through nodes, then > for example a mix node could create a new BXDF that can do more clever > importance sampling. Neither seems particularly elegant or transparent > to the user to me, but I can't think of good alternatives at the > moment. That's basically what Mantra PBR does, explicitly with the bsdf data type/node connections. The output node has a bsdf input, so for situations where you just need to find an outgoing scattering direction, you a) get the final bsdf arriving at the output via the node tree, and b) pass that final bsdf to the sample_bsdf() function. The more I understand about this, the more I really think it's the right way to go. They've really done an excellent job coming up with a modern system, without the 90s trappings, and with the flexibility of programmable/editable shading. I'd really like to see Blender head down that path too as a design that will serve us for the future. cheers, Matt [1] http://wiki.blender.org/index.php/User:Broken/RendererResearch#my_own_experiments.2C_july_09 [2] http://www.sidefx.com/docs/houdini10.0/vex/functions/eval_bsdf [3] http://www.sidefx.com/docs/houdini10.0/vex/functions/sample_bsdf ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Shading System Proposals
From: "Matt Ebb" >> Matt proposes a Sample_F output here but it's not entirely clear to me >> how this works, I also couldn't understand from the Houdini >> documentation for example if their BSDF F value is just a >> vector/scalar value or also contains information on how to sample it. > > I've done some research on this, and I think I have a fair idea of > what's going on in there. I actually suspect it's quite similar to > what I was toying around with before [1]. Rather than containing > merely values, the brdf type probably contains some function pointers > to pre-made functions (i.e. lambert distribution, phong distribution, > etc), since that's really the only way to represent a Scattering > Distribution _Function_. It also contains some other flags to say what > kind of scattering it can represent (diffuse, glossy, specular, > emission) etc, and probably some custom data to represent bsdf > parameters (like a glossiness slider). > I'm guessing this via a few VEX functions: > * sample_bsdf() [2] that takes a bsdf, 2d random samples, and shading > geometry as input, and returns an outgoing vector - eg. for lambert a > cosine weighted vector in hemisphere, and > * eval_bsdf() [3] which takes a bsdf and shading geometry input and > returns a colour (proportion of light that's reflected) - eg for > lambert, L.N . Just a thought, In the literature, it is common to name the BRDF as a function f in equations. f usually takes wi and wo as parameters: the incident and the exitant vectors and it returns the proportion of incoming radiance that is reflected back in wo direction. Also written as f(wi -> wo) to better indicate the direction. All other surface properties and geometries are implicit. Maybe the Houdini F comes from that? Yves ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
