[Bf-committers] bridging faces algorithm
Hi guys :) I have being trying without much success to search for an algorithm to perform bridging between vertices rings... I have heard about a modified Bresenham rasterizer to perform this O.o but I cant find any resource regarding this... did you have a clue? Thanks in advance. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] bridging faces algorithm
Oh yes thanks, I saw it and is quite powerful, but I'm trying to learn the theory behind it, the language independent code... Cheers De: Peter K.H. Gragert Para: Raul Fernandez ; bf-blender developers Enviado: miércoles 7 de septiembre de 2011 17:58 Asunto: Re: [Bf-committers] bridging faces algorithm Look at the looptool: Bridge! 2011/9/7 Raul Fernandez Hi guys :) > >I have being trying without much success to search for an algorithm to perform >bridging between vertices rings... I have heard about a modified Bresenham >rasterizer to perform this O.o but I cant find any resource regarding this... >did you have a clue? >Thanks in advance. >___ >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] bridging faces algorithm
Thanks a lot! yes, also convex hull algorithm may work too ;) Cheers!!! De: Sergey Kurdakov Para: Raul Fernandez ; bf-blender developers Enviado: miércoles 7 de septiembre de 2011 19:15 Asunto: [Bf-committers] bridging faces algorithm Hi Raul, I think, that general algorithm like constrained delaunay triangulation will fit - because what is needed -to have a mesh to fit into boundary points between two rings and it is what constrained delaunay will do, so docs from http://gts.sourceforge.net/ or docs at http://tetgen.berlios.de/ for http://tetgen.berlios.de/features.html#F3 might be of help. Regards Sergey ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] bridging faces algorithm
Thanks Bart, is suspected it was not universally applied but is a nice implementation though ;) De: bartius crouchPara: bf-blender developers Enviado: miércoles 7 de septiembre de 2011 21:01 Asunto: Re: [Bf-committers] bridging faces algorithm On Wed, Sep 7, 2011 at 4:58 PM, Peter K.H. Gragert wrote: > Look at the looptool: Bridge! That's probably not a very good idea, as I mainly tweaked the bridging to give proper results with often used situations. There isn't any real algorithm behind it, only some nonlinear least squares methods. Bart (coder of LoopTools: Bridge) ___ 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] bridging faces algorithm
Thanks Bart, I suspected it was not a general solution but is still a very nice implementation, Cheers De: bartius crouch Para: bf-blender developers Enviado: miércoles 7 de septiembre de 2011 21:01 Asunto: Re: [Bf-committers] bridging faces algorithm On Wed, Sep 7, 2011 at 4:58 PM, Peter K.H. Gragert wrote: > Look at the looptool: Bridge! That's probably not a very good idea, as I mainly tweaked the bridging to give proper results with often used situations. There isn't any real algorithm behind it, only some nonlinear least squares methods. Bart (coder of LoopTools: Bridge) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developers IRC meeting notes, 18 september 2011
Just a feature difference: - merging unconnected geometry, but no fundamental difference :P Cheers De: pete larabell Para: bf-blender developers Enviado: jueves 22 de septiembre de 2011 17:42 Asunto: Re: [Bf-committers] Blender developers IRC meeting notes, 18 september 2011 How much different is this than U.C. from Farthsary? > -Nicholas Bishop is working on "Sculpting Meshes with Self-Adaptive > Topology" http://liris.cnrs.fr/publis/?id=5105 > ___ 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] From Farsthary :)
@Nicholas I saw with great pleasure your recent development on Dynamic Sculpting, as my lack of free time was preventing me to fulfill my promises with the Blender community that have helped me so much in the past and I never forget that, so I have being carrying with a conscience burden every day for not finishing Unlimited Clay. What I want to propose you is, if you agree, I can help you integrating UnlimitedClay features, since you have done most of the part that was limiting it (handling a dynamic PBVH). of course, I know you are more than capable to get there on your own (you know? when I started the UC project I was never thinking in getting it so far, all I wanted to do was to show a good technical demo to attract your interest as the main Sculpting dev so it would be integrated in Blender successfully as previously I got a great help from Matt Ebb and Jahka for the other projects that started also as technical demos :P ) and I even think it would not be necessary because from your current implementation it would be relatively "easy" to add dynamic detail like in UC, with all the respect the author deserves I consider the "constant edge length" in the Freestyle implementation an artificial limitation rather than a fundamental limitation of the algorithm, In LC I could easily fit the dynamic topology with the dynamic subdivision to any level without any problem because it was not a fundamental requirement of the dynamic topology algorithm. And I agree that the main limitation can be now the lack of neighborhood information in current Blender mesh data structure, that's why I have put my hopes on Bmesh in the past. Please feel free to contact me at any time :) Cheers Raul ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Dynamic subdivision sculpting (Unlimited Clay) paper
Hi guys Some time since my last invite to my blog, I have uploaded there a paper I was working few month ago for SIGGRAPH 2011 regarding UnlimitedClay, it explains few interesting things if you want to deepen in it I hope this small contribution will be of some value, especially for you Nicholas :) http://farsthary.wordpress.com/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Cycles movement blur
Is interesting a full unbiased solution to motion blur can be instead or sampling (rendering) a point in time scene (static) to fully sample(in a random or pseudo random) way an interval scene (like the aperture size of the camera) though this may be more efficient in terms of required samples it can be costly in terms of memory because you have to have simultaneous access to a range of scenes instead of one, I don't know how Cycles engine deal with memory and frame scenes tough ... those are my two cents ;) De: Knapp Para: bf-blender developers Enviado: martes 15 de noviembre de 2011 22:46 Asunto: [Bf-committers] Cycles movement blur I was just thinking today that Cycles could do motion blur without taking a big CPU hit. I don't know much about all this so I bet my ideas is wrong or old but I thought I would post it just in case. When we do animation the computer calculates tweens and moves stuff for us. It does this once per frame. Cycles does many render cycles per frame. It struck me today that if at each cycle pass you move the object you would get a blur effect. I was also thinking that you might move it every 100 out of a 1000 pass to get interesting stutter effects. I look forward to hearing if my idea was good or only trash. BTW I would love to see a pause on the main render. Cycles eat my CPU alive and does not let me do much in the background. A nice/slow button might be good too but I am sure I am not the first to say this. Thanks for all the really cool work!! I love cycles, dynamic paint, motion tracking and ocean sim! All the other stuff is more in the background but I am sure I will be loving it too once I find it! -- Douglas E Knapp Creative Commons Film Group, Helping people make open source movies with open source software! http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php Massage in Gelsenkirchen-Buer: http://douglas.bespin.org/tcm/ztab1.htm Please link to me and trade links with me! Open Source Sci-Fi mmoRPG Game project. http://sf-journey-creations.wikispot.org/Front_Page http://code.google.com/p/perspectiveproject/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Surface from particles (Farsthary)
Hi all :) I have started to implement the surface generator from the particles, currently I'm on early stages and I get pretty crude and slow results, but is working :) There's a lot of things that I need to investigate also so will be very wellcome papers and resources.(for example fast surfacing methods, etc.) since for particle methods there's no much public aviable information (at last for me). I also need to learn more OpenGL and how it works with Blender methods, for example: what is the best/fastest way to display an array of triangles? I think Blender uses displist? but how does they works? what I'm doing rigth now is iterating over the triangle list and draw each one... This is a valuable skill when I tackle Voxel Sculpting again since that part will be central to the voxel scuplting method. As soon as I get better results I will post them :) Cheers Raul ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] flame density sampling problem
Hi :) > Hello again, > > I made some significant progress with the fire simulation system i > announced here earlier, thanks to the help of jahka, who convinced me > to integrate this into the particle system. Particles now form the > basis of the fire's flames, so we can uses them to further simulate > fire spread and other effects at a later time. See these videos for a > small impression of how this simulation works: > http://www.vimeo.com/album/166313 > Congratulations for your fast development rate :) > Now, in order to turn this physical simulation into actual images of > fire, i started work on the second big part of this fire system, which > is rendering. Since fire is essentially a fluid, a volumetric > rendering approach is a natural choice. So my first attempt to render > the flames was to use a point density texture, which describes the > flame density, emission and color from the underlying filament data > (those curves you see in the videos) and an associated density and > turbulence function. However, after a little test implementation and > after wrapping my head around how the creators of the original method > actually did this, i figured that this is not a good approach, last > but not least because rendering times get _way_ too big (here's the > original paper again: > http://reference.kfupm.edu.sa/content/s/t/structural_modeling_of_flames_for_a_prod_96921.pdf). > Well, rendering times could get longer but is not so bad approach, I think whatever method you came up , still a volumetric rendering option should be provided. Maya flame effects are very beautifull and are done with volumetric rendring , if you need further help on this feel free to contact me at ra...@info.upr.edu.cu. > So now i need some help to figure out how this could be done with > Blender's current rendering methods. I need to get a little deeper > into the math here: > > The problem is that directly evaluating the flame > density/illumination/etc. at a point in space is difficult, because of > two turbulence functions applied to the raw density function: > > 1. Let x be a point relative to a flame filament > 2. The density/color/etc. at this _untransformed_ point x is then > given by a function d(x) > 3. The point x is then transformed by a turbulence function T to a > point x' = T(x). This simulates turbulence of the surrounding air as > well as fluctuation of the combustion process and is essential for > realistic fire! > 4. In order to determine the actual density at an arbitrary sample > point s in space (which is what we need to do for volumetric > rendering), we'd have to calculate d( T_inv( s ) ), where T_inv is the > inverse of T, which is afaik not easily calculatable ... Pardon my ignorance in flame physics but since T is a turbulence function its inverse should also be a Turbulence function, and while for the simulation step you need some level of accuracy, for rendering some tradeoffs could be made, why not trying to render d( T( s ) )? , that means using the same turbulence function? could be a non sense, but you could try it ;) > The solution chosen by the authors of said paper is to generate a > complete set of point samples for the rendered flame volume in advance > and then transform these points all together. This creates a new set > of sample points, which is still sufficiently sampled due to the > coherence of the turbulence function. This however is more > complicated, since i'd have to influence the way samples for the > volumetric material are generated instead of just creating a new > texture method. My first implementation of volumetrics (the discarded path) have the flexibility to easily allow this, custom tailored sampling transformations in the volumetric sampling space, though at that time I thougth It never will be needed :) but the current implementation is more hardcoded/integrated to not allow this because is more oriented toward physical ligth behavior (ease of use, intitive) while the first volumetric code where oriented toward visualization (flexible, harder to use). For example a lost feature from the swap of volumetric implemenation was the adaptive sampling, which allowed more samples on high detail zones and fewer samples on uniform zones. But those are features that we can live without :) , more importantly is that another approaches should exist. >I also thought about simply assuming that, due to the > random nature of noise, the inverse transformation essentially looks > similar to the transformation itself, so one could just perturb the > samples before calculating the density, but i guess this would still > look odd. wow! i should have read the whole message before answer you :) , this is basically what i proposed before . > I am really just starting to get into the raytracing matter, so i > might just have overlooked a simple solution to this problem. Maybe > there actually _is_ an inverse to the turbulence transformation and i > didn't get it? > A
Re: [Bf-committers] Surface from particles (Farsthary)
Hi :) Thanks for the very fast repply ! @LetterRip Yes, I'm using a marching cubes algorithm and also have implemented the marching tetraedrom wich I have tested also , and while generate more precise surfaces is also slower, so i guess it could be left as a quality option for the user :) > In general the fastest way to draw an array of triangles in OpenGL is > with a VBO (vertex buffer object.) You can find examples of how to do > this in source/blender/gpu/intern/gpu_buffers.c. (I think the VBO code > was merged maybe two or three months ago? So your sources would need > to be at least that recent in order to see the VBO code there.) > > The basic idea is that you set set up a buffer to hold your vertices > (including at least vertex coordinates, plus optional normal and color > data) using glGenBuffers and glBufferData, then set up a separate > buffer object to hold the vertex indices that make up each triangle. > Then you can draw using glDrawElements. (Buffer objects are pretty > flexible, so you have a lot of control over how you split up your data > into different VBOs; for example you don't have to use an index buffer > object if you didn't have a lot of vertices used by multiple > triangles.) @Nicolas I will try it starting tonigth, seems a powerfull solution, thanks :) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Surface particles update
Hi everyone :) Thanks to all for the suggested resources , they where of great help I'm progressing a lot in the surfacing , I have implemented a spatial hash structure for boundless marching cubes acceleration that is working ok should I implement it as a new BLI_hash file or just inside the isosurface.c files? For the isosurface evaluation I still have to investigate few more approaches since I'm getting only surface slides of the fluid stream currently. Currently I have a lack of updates in my site because the college net is nearly collapse due to the VILSEL and several viruses of the same family that keep the network saturated :( KAV and NOD made very little for it, any effecyive solution ? Cheers Raul ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Particle surfaces update
Hi all Last nigth I have finishing implementing the surface refinement for particles, this allow to increase the resolution of the mesh for smoother surfaces. I still need to redefine my current surface evaluation from particles because I´m getting the wrong isosurfaces but still I could show you my progress. I'm very exited about it because I'm learning the necesary skills to tackle later Voxel Sculpting since are based on the same technologies :) Is not a beatufl pictures and for end users this may still tell noting but a month ago I only could dream about achiving this: http://farsthary.wordpress.com the longest journey start with a step ;) Cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Particles surface core is done :) !!!!
Hi everyone :) After a sleepless nigth I have finally fully implemented the particle surface generator core :) Many improvements and optimizations are remaining but the hard part is done , the fun starts now :) though is still heavily unoptimized it still performs at the same level of instanced metaballs. many things remain like the complete OpenGL visualization set using the VBO and stuffs like that that I need to research (currently is still using OpenGl inmediate mode for drawing) and implementing color blending among particles for the polygon mesh. Also i would like to implement a caching system like Elbeem (could be resued here?) for baking the simulation without need to recalculate the implicit surfaces like the current Metaball implementations do. probably I will need help on this I have updated my site: http://farsthary.wordpress.com hope you like this feature PS: i have tested it with boids also and works ok ;) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Particles surface core is done :) !!!!
Ops! > Also i would like to implement a caching system like Elbeem (could be > resued here?) for baking the simulation without need to recalculate the > implicit surfaces like the current Metaball implementations do. I mean "reused" not "resued" :) I guess "resued" could mean a dangerous word in english if ever exist such a word, LOL ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Particles surfacing speed boost :)
Hi all :) I have improved the particles surfacing algorithm and now it has a speed boost over my previos implementation of an order of magnitude , and is now near production ready, all of that without multithreading/OpenGL optimizations :P , so in the future there's lot of room for further speed gains. check my site: http://farsthary.wordpres.com hope you like it Cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Particle surface reconstruction (Farsthary)
Hi again when I started this project Erwin wrote: > We recently got a contribution of real-time SPH for Bullet, without > the rendering, so if you come up with some good implementation under > the ZLib license, we could use that within the BGE. > > (this SPH implementation is both for CPU and CUDA/GPU, done by Rama > Hoetzlein, see http://www.rchoetzlein.com/eng/graphics/fluids.htm ) > > Good luck, > Erwin And now that I'm close to reach production levels how should I release it to be compatible with Blender and Bullet? Thanks in advance ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Particle surface reconstruction (Farsthary)
Hi Erwin :) > Hi Farsthary, > > So you implemented some iso-surface generation for SPH particles? Yes, I have progressed a lot from my first attempts :) > Sorry I've been busy with trying to get Bullet 2.76 out of the door (still > more work), > but I'm interested in your work. > Thanks a lot! though I'm orders of magnitude more impressed for your work in Bullet. > Do you consider making it available under the ZLib license? > Thanks > Erwin Seems a good option, that way could be reused/modified in Bullet and in Blender. I still need to improve and polish more the code but I'm getting closer :) > By the way: have you tried to integrate it into the Bullet SPH > implementation by Hoetzlein (from the Bullet/Extras/sph folder)? I haven't look at bullet source code but i definatelly should dive into it as this project approach to its first iteration. I will first release the SPH engine for Blender particles and later the isosurfacing generator. Thanks! Raul ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Particles surfacing speed boost :)
Hi Aurel :) > Isn't marching cube very trivial to parallelize? > It should because cell polygonization is independent one from another but I have no experience in multithread programming in Blender, in what feature/files already coded could I look to learn how it is done? Thanks in advance Raul ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Particle fluids buoyancy... wellcome gases :)
Hi all :) las nigth I have implemented a buoyancy force for particle fluids that will allow simulation of gas particles, not just liquids that are the widespread solution, and since those parametters could be animated I start imagine boiling watter ;) visit my site for wispy smoke tests http://farsthary.wordpress.com Cheers Raul ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Particle fluids buoyancy... wellcome gases :)
Hi Lukas :) thanks :) > Have you thought about rendering gases yet? I guess this is a > different challenge, since you cannot approximate gases by a sharp > surface boundary (except for very stylized art perhaps). Point density > texture might be the right answer, but you may have to add additional > turbulence to get small scale detail. Point density textures already > support turbulence, not sure if that would be sufficient (afaik the > current smoke simulator uses a similar technique, using wavelet > turbulence for small noise frequencies or so. Just wildly guessing > from my limited knowledge.) That's currently the path to render particle gases, you're rigth ! > > I suppose you used a turbulence modifier on that empty to make those > particles move "randomly" ? If so, you might be interested in the flow > noise method i use, here's a small test video used with a volume > texture: http://vimeo.com/8929215. This could easily be applied to the > turbulence modifier to avoid the static behaviour (particles > essentially clumping in the same places all the time). Until now it > seemed i was the only one actually interested in this, so i didn't > make a patch yet, but it can be done quickly. I know very little about > actual fluid simulation, so i don't know if this "fake" turbulence > could/would be replaced by inherent fluid features. yes, those empties contain turbulent fields and your proposal of a better turbulent field seems very interesting ... so I preciate any collaboration in that :) > Just hope your particle simulation is not too efficient, so that there > might still be a place for my own fire sim ;) > Keep it up! > > Lukas Nah ;) , your approach is also very interesting and has potential , the good thing about Blender is that is a blender of 3D technologies ... a name never have being better choosen. Cheers and keep ut you to. Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Particle fluids update
Hi all :) I spend the hole weekend squeezing a bit more optimizations for the surface reconstruction from particles, I have implemented a marching step only to the surrounding voxels that contains the surface (and not to every surrounding voxels as before) also I have implemented corner value reusing (every new step reuse the half of the previous calculated voxel corner values) and finally I have rewritten my previous spatial hash code that use integer operations to reuse the metaballs bitwise hash functions all of this optimizations are pushing the surface generation to its limits, further speed up I think will be gained only with multithreading and or OpenCL but that is out of my current scope/skills. As a comparison note, this implementation has outperformed the metaball instanced particles by a huge margin. I probably will spend this week cleaning the code for make a separation between fluid particle engine and visualization engine and will send Jahka the first patch for review. Once integrated the fluid particles engine the efforts could be focused on renderable meshings :) Cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Particle Fluids engine patch at last! (farsthary)
Hi all :) Here's at last the first public patch of the Particle Fluids engine , this means that still don't have included the particle surfacing because is still a work in progress but the engine is pretty usefull in its current state and particles could be rendered via splatting or using pointdensity for more advanced volumetric particle effects (remember my pouring moss tests?) and finally you could use instanced particles to whatever you want , including metaballs, though those are not replacement for the upcomming particle mesh surface ;) I have sended the patch to Jahka for his expert review and commit, and once integrated in its final GUI form Stephen and me could start writting down documentation of the many features it have. I have included also two quick .blend test files to figure out of the settings PATCH: http://www.pasteall.org/11232/diff TEST BLENDS: http://www.pasteall.org/blend/1959and http://www.pasteall.org/blend/1960 The main actors of this achievements are Stephen, Jahka and your servant: Farsthary I will enjoy this part: Feedback Cheers to all and THANKS! PS: in the future the engine may change a bit because I'm researching ways to speed up simulations by data structures other than the kdtree it currently use ;) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Bugfixed Particle fluids patch
Hi all :) thanks to community feedback I have solved an initialization bug in the particle fluids code, here's the updated patch: http://www.pasteall.org/11270/diff is important to test this feature now before Jahka start reviewing and committing it. I provide test files in my site: http://farsthary.wordpress.com thanks in advance, Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] I'd like to kill the soft body module
Hi all :| > Hi all, > I've been watching 2.5 evolving and I feel the (one size fits all .. > experimental physics code) soft body module has been replaced by the far > better cloth module at the hot spots. ( Thanks will go to janne and daniel > ) Is good that one module function overlaps another module function, that speaks about how powerfull blender has became, but if they're well designed there will be always use cases optimized for Softbodies and clothes, furthermore, even if is not the case currently and softbodies may seems unmaintained, in the future other interested devs could take advantage of it an resume its development and improve it. > Further I think that future development ( in Blender ) should focus on > visual effects rather than try to simulate real world physics (which is > 'in given range' mission impossible ) . And what are visual effects without physically based simulations? faking effects are clever, perform fast and several pros but always will miss something that only could be achieved with physically based simulations and are difficult to make. I don't think making Blender a "you-must-build-and-fake-everything" will be a good option. One thing is physically accuracy (that we should avoid because its price is speed) and other is visual realism. I do think that physics simulations (ranging from rendering (physically based ligth behavior) to cloth, particles, character animation) have a brigth future in Blender and will make a difference because they bring realism to the masses. > So I'd like to kindly ask for the permission to remove that wrong view > angled, physicists, crappy code. > BM I would like not to remove it , just in case it makes more harm than good, is sad to drop countless man/hours, efforts and knowledge, but I guess is just me and is only my personal choice. cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Particle fluids status
Hi all :) Just a quick update: I'm working with Jahka refining the final patch, thanks to its feedback abd the users feedback I will modify several things in the final patch, like default values and remove some small things that are in future particle system design roadmap. Next week when Blendiac and WhifeofBlendiac return home they will upload several very interesting high resolution screencasts I have made on some use cases of particle fluids. Including a very interesting one using particle fluids to simulate sand (high number of small solid points that interact with its closest neighbours) of 100k particles, at near 1 fps simulation. Cheers to all Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Unified physic simulation (Lagrangian)
Hi Thomas :) Thanks for the links! I will review it as soon as I get connected again. the SPH implementation is quite powerfull and easy to extend, hopefully Blender will have soon an SPH framework. Cheers Farsthary > Sorry I forgot the link to the animations: > http://www2.cs.kuleuven.be/~graphics/publications/LenaertsPhD/animations.php > ___ > 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] Particle Fluids Engine corrected patch
Hi all :) Thanks to Jahka review and advices I have corrected the particle fluids patch and have simplify it for better integration. Also I have discovered and solved an important bug in the multi-fluids interaction that cause strange behavior in fluids. here you will find the new patch: http://www.pasteall.org/11805/diff and here a new test blend: http://www.pasteall.org/blend/2223 The short list of changes are: Important multifluids bugfix, better defaults and parameter naming and a cleaner patch. I have temporarily removed the particle color and temperature visualization since are targeted for future design in Jahka framework, but once committed the code will be easy to add back. I will soon upload a pdf with all the features of particle fluids. Once committed I will focus back on the surface creation over a fresh SVN oficial build ;) Cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender security paranoia
Hi all :) WARNING: this email is not targeted to anybody in particular, is just my opinion and I like to learn from my mistakes :) I think is good to think in all threat possibilities that could arise in the future but I really don't understand all the paranoia that has being awaken toward Blender. It makes more harm than good because it introduce the fear in the Blender ecuation , the user that will make .blend content that is worth downloading and sharing will not burn his hard earned reputation in making scripts for stealing user information or deleting user files. C'mon we are 3D guys working hard for making well, you guess, 3D , is very different from people killing time writing trash on Word or Power-points and also from a malicious developer point of view the user share of Blender (and really from any 3D app) is not worth it. In all the blender history mention a case when something like that have happened before. And while that is not a strong argument that prevent such situations from happening in the future I think such level of security is an SO duty, not an app task. Blender could not live without python and making mechanisms for avoid automatic and hiding script running is OK, but I think we should not take that further. Regards farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Particle fluids videos uploaded
Hi all :) Thanks to Blendiac aid now there`s several particle fluids video tutorials uploaded. Though things has changed from the time I record those videos, the workflow and remain very similar and from watching it users could grasp how is working with particle fluids. I also provide a video of how to render them as volumetric point density particles and some sand simulations. visit my site for more details: http://farsthary.wordpress.com hope you like them. regards Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Volumetrics for cartoon shading? and fluid particle status
Hi all Did someone have found something similar before on volumetrics? Tinkering with volumetric solids I have found that could be used for cartoon shading also. check my site for more details: http://farsthary.wordpress.com Regarding fluid particle status Jahka has given an incredible helpful feedback and contributions and also green light for integration, I'm just waiting for him to commit to resume the surfacing work, plus some other acceleration techniques I plan to apply. Cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] version naming
Hi :) +1 Agree, for non devs talking in decimal terms diminish the wow factor ;) so 2.49, 2.50, 2.51 , etc hide the huge change Blender have experienced. Is better a versioning system that reflect the magnitude of changes: Major Version . Minor Version . Bugfixes Major Version represent a core revamp/refactor, (like from 2.49 - 2.5) so is better from 2 to 3 Minor Version represent new "big" features added and Bugfixes represent , well, exactly that and alo minor features and tweaks The problem of using whole numbers from one version to another is that with the development rate of Blender we will reach very quickly the Maya/Max (in gradual revamp process also) and C4D ;) Cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] From Farsthary moving colliders patch
Hi Janne :) Starting the documentation I have exhaustive tried the commit and have found several issues, hopefully I have the solution for two or the three problems I have found. First the moving fluid emitter: when you play a fluid sim and start moving emitter particle fluids inherit the moving emitter speed which is not a desired feature. I was suspecting it was due to some relative velocity therm and I was rigth , here's the patch (is fairly simple, just a line of code): //- Index: source/blender/blenkernel/intern/particle_system.c === --- source/blender/blenkernel/intern/particle_system.c (revision 28047) +++ source/blender/blenkernel/intern/particle_system.c (working copy) @@ -2308,8 +2308,7 @@ VECCOPY(start, pa->prev_state.co); VECCOPY(end, pa->state.co); - sub_v3_v3v3(v, end, start); - mul_v3_fl(v, 1.f/dtime); + VECCOPY(v, pa->state.vel); neighbours = BLI_kdtree_range_search(tree, radius, start, NULL, &ptn); //- While the previous approach aparently is more stable, when the user move the emitter, the difference between end and start position, quickly jump and is no longer a measure of the particle initial velocity. Moreover, that older approach ignore completely the particle speed Damp factor, you could change it and nothing happens, that is the second issue that is now solved with the new approach. And the more anoying issue is regarding the random particle explosions that happen with colliders. Tracking down the issues I have found that it has nothing to do with the SPH because it worked perfectly with older revisions, and seems to be due to recent changes that have being commited to the particle mesh colliders code ... what where those changes? That is a special problematic issue because it is prevempting from propper collissions and fill containers because everything explodes. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Patch to SPH particles moving emitter issue
Hi all :) When you play a fluid sim and start moving the emitter, particle fluids inherit the moving emitter speed which is not a desired feature and a second bug caused from the previous code was the ignore of the absolute particle velocity Damp factor. Here's the patch (is fairly simple, just a line of code): //- Index: source/blender/blenkernel/intern/particle_system.c === --- source/blender/blenkernel/intern/particle_system.c (revision 28047) +++ source/blender/blenkernel/intern/particle_system.c (working copy) @@ -2308,8 +2308,7 @@ VECCOPY(start, pa->prev_state.co); VECCOPY(end, pa->state.co); - sub_v3_v3v3(v, end, start); - mul_v3_fl(v, 1.f/dtime); + VECCOPY(v, pa->state.vel); neighbours = BLI_kdtree_range_search(tree, radius, start, NULL, &ptn); //- While the previous approach aparently is more stable, when the user move the emitter, the difference between end and start position, quickly jump and is no longer a measure of the particle initial velocity moreover, that older approach ignore completely the particle speed Damp factor, you could change it and nothing happens, that is the second issue that is now solved with the new approach. The random particle explossions issue is something we are working on, it dosen't happen in older builds (27326 and olders) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Small apologize
The first email was intended for Jahka only and the second for the list, by accident I sended both at the same email :( I apologize for that and sorry for triple posting. Regards Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Sub frame calculations for particle systems done!
Hi all :) Stability is one of the most desired feature of a simulation and in particle systems is a must have. The particle fluids exhibit random explosions (which I think could be reduced because in older SVN revisions that doesn't happen) and in general the particle systems have a leaking trough wall containers behavior when the container rotates. (think of the typical wine glass falling example :) ) As a suggestion from Jahka and several members of the community I have implemented particle subframe simulations not just for particle fluids but for the whole particle system. Subframe simulations greatly increase the stability of the simulation to any desired level, it basically perform a user defined number of pre-simulations in between frames, allowing finer grain sims, and a nice side effect of it is that now particle-surface collisions could be properly captured so there's no leaking effect when containers rotates. Subframe simulations do increase the calculation time proportionally to the number of sub-steps, so the user have to made a trade-off between stability and simulation time. But the good news is that there's now a lot of methods to reach stability in the particle systems so a combination of them will help to get very low substeps (even none) to get stable simulations and proper particle collision detection very fast. I have recorded several videos of the feature in action, and as soon as I get connected today I plan to upload and publish the patch. Regards Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Sub frame calculations for particle systems done!
Videos are now uploaded, check my site http://farsthary.wordpress.com and here is the patch: http://www.pasteall.org/12304/diff cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Sub frame calculations for particle systems done!
> > Raul, > > The videos are set to private. > > -Sean > Ops! sorry, I have changed to public, hope it works now! Thanks! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Improved Group restriction patch (previous Group as layer patch)
Hi all :) Some time ago I have coded a group aslayer patch that suffer from several small drawbacks, mainly in the GUI part and not in the conceptual level. Also I must confess that my previous patch was awfull to review and apply :P So I take some time to rewrite it from scratch and improve it a little. Now is much more functional and easy to apply/integrate than before! This patch basically add the posibility to toggle visualization, selectability (freezing to avoid accidental modifications) and renderability of entire groups of objects , replicating the functionality of a layer manager because groups could be already renamed and managed in ways that a layer manager could not do (but the main target is not a re layer manager, just another usefull tool for huge and complex scene management), that´s why I called it Groups as Layers patch before, it extend the functionality of groups in the outliner in a natural and very needed way: If you want to be able to arrange your objects in logic ways, for example, the most basic realistic mechanic modeling could have hundreds of parts, then 20 layers is not enough, you want a layer named bolts, other named gears, and many more that soon will pass the 20 limit ;) In my site I have upload some videos showing it in action in basic scenes I hope you like and will be very pleased to receive some reviews/opinions about it, and I hope with this second attempt we have a winner Cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
I hope I'm wrong and is something I have missed from the "Security" discussion but is leading to dangerous thougths Dropping python?!?!?! Python support has being one of the best steps Blender has ever made, even before the industry standard packages start considering python (when each one implement their own scripting language leading to a migration chaos among them) I think dropping python is not an option, is a suicide ;) and is definatelly more harming than all the possible threats that is suppose to solve. -1 ad infinitum :) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
Is time to end up this security discussion: paperware is very beautiful but never leave the planification phase. The pro-security team could work on a prototype that could shut up the rest of us that think this discussion is getting in the way, meanwhile, the rest of us could continue improving blender. regards farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "Security" gets in the way
> Raul Fernandez Hernandez wrote: >> Is time to end up this security discussion: paperware is very beautiful >> but never leave the planification phase. >> The pro-security team could work on a prototype that could shut up the >> rest of us that think this discussion is getting in the way, meanwhile, >> the rest of us could continue improving blender. > > Are you speaking for the Blender development team or just yourself? > Serious question as I'd like to know if the opinion that adding security > is not part of "improving Blender" is shared at the top level. After > all, if Ton (for example) doesn't want there to be a security option - > there simply isn't going to be one as it will never get into trunk. > > There is no point makling a prototype if the end-result is already > predetermined as "we don't want it". Don't get me wrong, I have no intention of discrimination , I think the fact that english is not my way of thinking could lead to this. I was speaking for myself , splitting in pro-security and the rest is very natural when a discussion arise, is nothing bad, and when I was referring to "the rest of us could continue improving blender" I didn't mean that working in security was not improving blender, I mean: "the rest of us could continue working in their projects in blender". I think a working patch or prototype is way better than a long discussion that sometimes get out of its path, nothing more. Cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Spatial hashing
Hi all I'm currently developing/researching a spatial hashing structure as an alternative to the particles kdtree, hashing has several advantages over hieraquical data structures like trees like O(1) insertion, and linear worst case queries (and other drawbacks) that's why I'm investigating if there are performance gains under high particle numbers (where hashing shows advantages over trees) I preciate if anyone could suggest me good resources on spatial hash integer functions, and a way to measure the exact calculation time in order to compare both algorithms Cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] The final step that Blender needs to take in order to become fundamentally perfect
Hi there > I know resources are limited but what is to stop a few from starting a > branch and exploring this very interesting area? I could see it as > being a nodal extension of the game engine. I do admit to knowing very > little about this subject but that is what it looked like in that > SUPER cool video. You cannot fork Blender for a "huge" revamp in its current state, when haven't finished the previous revamp because then the sync back could become near impossible, you could base your entire codebase in things that simply will change or could dissapear in the official branch. Only after few stable releases you could fork Blender for a major architecture change like this. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Spatial hashing
Hi :) Thanks for the links, sadly i could not access googlecode (is part of the embargo issue) and also the sourceforge issue remain ... I haven't being able to download a single bit from them. Anyway, thanks, I have performed several test and hashing will not provide much more advantage over the current kdtree because the performance bottleneck in the particle systems is not in the spatial structure, I will make a few tests more with the blender BLI_ghash module (I just have discovered it ;) ) > Google gave me these: > http://perfecthashing.googlecode.com/files/perfecthash.pdf > http://code.google.com/p/perfecthashing/ > > I admire your work Raul. > ___ > 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] Spatial hashing
Yes, I have tried Tor but it makes so sloow my already slow connection that is practically not an option, loading a clean page like google takes ages, not even think on downloading :( Cheers Raul > Shame on Google. > > Have you tried something like Tor: > http://www.torproject.org/index.html.fr > > Maybe it can help. > > > 2010/5/10 Raul Fernandez Hernandez : >> Hi :) >> >> Thanks for the links, sadly i could not access googlecode (is part of >> the embargo issue) and also the sourceforge issue remain ... I haven't >> being able to download a single bit from them. >> >> Anyway, thanks, I have performed several test and hashing will not >> provide much more advantage over the current kdtree because the >> performance bottleneck in the particle systems is not in the spatial >> structure, I will make a few tests more with the blender BLI_ghash >> module (I just have discovered it ;) ) >> >>> Google gave me these: >>> http://perfecthashing.googlecode.com/files/perfecthash.pdf >>> http://code.google.com/p/perfecthashing/ >>> >>> I admire your work Raul. >>> ___ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >> >> >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Compiling Blender on CodeBlocks/MinGW
Hi I generate the Makefiles and the CodeBlocks files with CMake without problems but when I compile the project in Codeblocks I get this errors C:/Blender_Build/blenderSVN/intern/ghost/./GHOST_Types.h:45: error: `__int64' does not name a type mingw32-make.exe[1]: Leaving directory `C:/Users/Raul/Desktop' C:/Blender_Build/blenderSVN/intern/ghost/./GHOST_Types.h:46: error: `__int64' does not name a type C:/Blender_Build/blenderSVN/intern/ghost/./GHOST_Types.h:438: error: `GHOST_TUns64' does not name a type C:/Blender_Build/blenderSVN/intern/ghost/./GHOST_Types.h:439: error: `GHOST_TUns64' does not name a type C:/Blender_Build/blenderSVN/intern/ghost/./GHOST_Types.h:443: error: `GHOST_TUns64' does not name a type C:/Blender_Build/blenderSVN/intern/ghost/./GHOST_Types.h:444: error: `GHOST_TUns64' does not name a type C:/Blender_Build/blenderSVN/intern/ghost/./GHOST_Types.h:492: error: `GHOST_TUns64' has not been declared C:/Blender_Build/blenderSVN/intern/ghost/./GHOST_Types.h:492: error: ISO C++ forbids declaration of `time' with no type mingw32-make.exe[2]: *** [intern/ghost/CMakeFiles/bf_ghost.dir/intern/GHOST_Buttons.cpp.obj] Error 1 mingw32-make.exe[1]: *** [intern/ghost/CMakeFiles/bf_ghost.dir/all] Error 2 mingw32-make.exe: *** [all] Error 2 Process terminated with status 2 (0 minutes, 17 seconds) 8 errors, 11 warnings any help/hint? I'm compiling on Win7 64 bits Cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Dynamic Sculpting Tessellation (Sculptris main feature) in Blender (Farsthary)
Hi all :) Well, this is another code surprise I have prepared for the community ... I fell in love with 3D Coat Voxel Sculptig and with Sculptris dynamic tesselllation on the fly , both approaches , although very different under the hood tackle the same problem: artistic freedom and unlimited clay, in both features there's no need to worry for polygon stretching while you sculpt! Some time ago I have contacted the developer of Sculptris hoping for hints or help to implement that on Blender, sadly he has not the time to do that. but anyway, I like challenges and having in my mind the goal, the path will be revealed ;) But few days ago with the revival of the Sculptris interest I decided to ush myself a little and at least implement a basic working prototype, but the results although still is non ready for production and I'm sure is not optimally implemeted, has surpassed my initial expectations for the first teration. Since Mesh/Sculpting is not my main field rigth now, I would preciate the further help of experienced devs on this are to make a decent/production ready implemetation of this very useful tool. I have sended to Lapinou a video showing it in action, so he will update soon my blog. http://farsthary.wordpress.com Keep in touch , I'm very excited about it and can't stop playing with it. warning: it lacks currently a lot of functionality and is not a Sculptris competitor, but every plant start as a seed ;) Cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Dynamic Sculpting Tessellation (Sculptris main feature) in Blender (Farsthary)
Hi all Lapinou have upload a new video I have send him of dynamic sculpt tessellation with few improvements. http://farsthary.wordpress.com I will soon release the code and or integrate this feature in my experimental branch. At that point I will preciate the review and aid of an experience sculpting dev to take it further. Cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] documented creating a custom modifier
Hello Ian > Hello all, > > I did a quick writeup of my experience creating a custom modifier. It > doesn't do anything but printf when its added to an object, but hopefully > this post can prove useful to new devs (such as myself ^_^) > > http://enja.org/2010/05/24/blender-creating-a-custom-modifier/ > > I couldn't find this process documented online. The closest was this > unfinished tutorial: > http://wiki.blender.org/index.php/Dev:Doc/How_to/Add_an_Object_Type > > I would appreciate any feedback (especially if I'm wrong about something) > and I would be happy to add this to a wiki or something, I'm just too new > to > the community to know where it would go! > Tomorrow I'm going to try adding some functionality to my modifier, and > also > have it affect how the object is rendered in the game engine. Hopefully > I'm > on the right track! > > -- > Ian Johnson This kind of tutorials are of great help for new devs and devs that covers wide areas of Blender, I think this ind of step by step tutorials provide a very valuable and easy road to be initiated in development :) Thanks Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] a quick question
Hi all :) I'm about to commit to my branch the Unlimited clay feature for sculpting, but I'm getting troubles trying to set up the default value for the new property brush.detail, in the RNA the range is 0.05-1.f where 0.05 subdivide a lot the mesh and 1.0 is quite rough so the default vaue should be 0.25 but I could not find the place where the brush get its default value add_brush() only works with newly created brushes, not the ones that exite when Blender start If I get a quick answer I could commit by today Thanks in advance Raul ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] a quick question
Hi :) Thanks for the really quick repply ... yes, I think I will commit without the default value and then an experienced dev could do that, after all is what open source is about ;) The default value of 0.05 is very dangerous because it subdivide a lot the mesh, so 0.25 is a safer value. I will start trying to get connected and write some quick information regarding unlimited clay for users Thanks a lot Raul ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Unlimited Clay committed
Hi guys! I finally committed the unlimited clay feature to my branch: it have several design desitions that should be discussed later like the exposing the mesh tools (though I think are rigth ;) ) A warning: it dosen't work with multires currently, seems that multires don't initialize few fields that are needed for unlimited clay and crashes A warning: while is not set to a correct default around 0.25 , when activated, the detail property is set to 0.05, rise up to 0.25! And few differences compared with Sculptris: Sculptris use a different mesh system and different mesh subdivission scheme, but that is only the make up, the underlying algorithm is the same and in the future the blender mesh subdivide tool could and should be improved, also Bmesh will provide new tools to toy with :) all of this is independent to Unlimited Clay because is designed to be very modular, it simply use existent Blender mesh tools :) Currently I have designed to do the subdivision at stroke finish step, while sculptris perform this step all the way while the stroke is executing, this is something that could be improved in the future, another make up difference. I hope it will be at least usefull as a seed for a powerfull feature. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Unlimited Clay committed
and here's the patch http://www.pasteall.org/13481 Cheers Raul ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] a quick question
Hi Thanks a lot :), as soon as I get connected I will fix that. > Changing the default .blend also would not be enough, since existing > .blend files still wouldn't be converted. Here's the code you can add > at the end of do_versions in readfile.c. > > for (brush= main->brush.first; brush; brush= brush->id.next) > if(brush->detail == 0.0f) > brush->detail = 0.25f; > > Brecht. > > On Mon, May 31, 2010 at 9:58 PM, Diego B wrote: >> If it's the default value, before change the default blend, you can >> try with a do_versions. >> Change the default blend file always come with problems ;) >> >> On Mon, May 31, 2010 at 4:51 PM, Daniel Salazar - 3Developer.com >> wrote: >>> BTW this should be done very carefully, if you want you can just >>> commit like it is and I will fix the defaults later? >>> >>> cheers >>> >>> Daniel Salazar >>> www.3developer.com >>> >>> >>> >>> On Mon, May 31, 2010 at 1:49 PM, Daniel Salazar - 3Developer.com >>> wrote: >>>> Hi Raul, those are actually saved in the B.blend.c file >>>> (/blender/source/blender/editors/datafiles and you would need to >>>> generate a new compilable default blend file using the datatoc.py >>>> script included in release >>>> >>>> pura vida! >>>> >>>> Daniel Salazar >>>> www.3developer.com >>>> >>>> >>>> >>>> On Mon, May 31, 2010 at 1:45 PM, Raul Fernandez Hernandez >>>> wrote: >>>>> Hi all :) >>>>> >>>>> I'm about to commit to my branch the Unlimited clay feature for >>>>> sculpting, but I'm getting troubles trying to set up the default >>>>> value >>>>> for the new property brush.detail, in the RNA the range is 0.05-1.f >>>>> where >>>>> 0.05 subdivide a lot the mesh and 1.0 is quite rough so the default >>>>> vaue >>>>> should be 0.25 >>>>> but I could not find the place where the brush get its default value >>>>> >>>>> add_brush() only works with newly created brushes, not the ones that >>>>> exite >>>>> when Blender start >>>>> >>>>> If I get a quick answer I could commit by today >>>>> >>>>> Thanks in advance Raul >>>>> >>>>> ___ >>>>> Bf-committers mailing list >>>>> Bf-committers@blender.org >>>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>>> >>>> >>> ___ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Unlimited Clay committed
Ops! I didn't know I have to suscribe also to a new mailing list, when I get online again I will see that :) Also, devs that find new aditions or good solutions for Unlimited clay are encouraged to commit to my branch. Cheers Raul > It seems to be this commit (29110) > https://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=29110 > > 2010/5/31 Daniel Salazar - 3Developer.com : >> I didn't see the commit on the mailing list :o are you sure you >> commited to you branch? >> >> cheers >> >> Daniel Salazar >> www.3developer.com >> >> >> >> On Mon, May 31, 2010 at 3:04 PM, Raul Fernandez Hernandez >> wrote: >>> >>> and here's the patch >>> >>> http://www.pasteall.org/13481 >>> >>> Cheers Raul >>> >>> ___ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Unlimited Clay committed
Hi I have committed the default value fix, thanks! now should be better I will try to post today a basic tutorial and explanation on how it works Cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Unlimited Clay committed
> There are several places in the code that do not compile with MSVC because > it does not allow you do declare variables after the beginning of a block. > > For example there are many places where EditMesh* is declared. I'll > commit > the code that doesn't compile for me, then after that I'll commit a > version > that works with MSVC. > Ok, I'm unaware of those restrictions because I compile with gcc in windows and linux ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Unlimited Clay committed
Yesterday I have committed a new patch that add a new property to the unlimited clay: smoothness, that controls the subdivission smoothness here's the patch: http://www.pasteall.org/13522/diff @Letterip: Oh, I will need to apply tose fixes too :) Cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] farsthary-branch small commit
properly free the editmesh resources on each creation (should be better memory wise now) and also applied the fix that Letterrip do regarding extending the sculpt flag from short to int. Index: source/blender/editors/sculpt_paint/sculpt.c === --- source/blender/editors/sculpt_paint/sculpt.c(revision 29142) +++ source/blender/editors/sculpt_paint/sculpt.c(working copy) @@ -599,9 +599,11 @@ /* Clear selection */ for(eed = me->edit_mesh->edges.first; eed; eed = eed->next) EM_select_edge(eed, 0); load_editMesh(ss->scene, ob); + + free_editMesh(me->edit_mesh); DAG_id_flush_update(ob->data, OB_RECALC_DATA); //? } Index: source/blender/makesdna/DNA_brush_types.h === --- source/blender/makesdna/DNA_brush_types.h (revision 29142) +++ source/blender/makesdna/DNA_brush_types.h (working copy) @@ -54,8 +54,9 @@ struct CurveMapping *curve; /* falloff curve */ struct MTex mtex; - short flag, blend; /* general purpose flag, blend mode */ - int size; /* brush diameter */ + short blend, pad; /* blend mode */ + int size; /* brush diameter */ + int flag, pad3; /* general purpose flag */ float detail; /* dynamic subdivission detail */ float smoothness; /* dynamic subdivission smoothness*/ float jitter; /* jitter the position of the brush */ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Realtime unlimited clay
Hi all :) Thanks to the help of Nicolas Bishop I was able to implement Unlimited clay in realtime :) Still I have to improve it to make it usable at high polycounts but is definatelly a step in the rigth direction and the main missing feature. Lapinou will soon update my blog with a third video showing that functionality combined with Subsurf modifier that provides an interesting workflow :P Cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Unlimited clay status
Hi all A quick status report with good and bad news: The good first :P I'm ready to commit when I get connected again the new patch that add the possibility to get realtime feedback as the user subdivide the mesh, I have set it as an option, becasue as I have feared for high polycounts is still better to have it updated at stroke end. I think this kind of flexibility is good, now the user have tree levels -Normal sculpting (current workflow) -dynamic subdivission (realtime unlimited clay) (Low res) -static subdivission (non realtime unlimited clay) (Hi res) The low res and high res threshold is machine dependant and not written in stone ;) And ow the bad one: Since the current sculpting system wasn't designed for dynamic topology the PBVH tree which is based has no fast update function to handle changes in topology without need to rebuild the entire tree, so the current solution use the rebuild PBVH tree option that is painfully slow for realtime update at relative low polycounts. But a derived good news is that such a function could be implemented, and now that the problem is spotted, is the next goal to achieve. the new BLI_pbvh_update_mesh() function should insert the new subdivided faces/verts in the tree as sugested by Nicholas Bishop ... a question though: What is the best expected time for updates in a PBVH tree? I will preciate the help of the creators of the pbvh structure, a quick explanation on how it works could save me lot of time trying to understnd it from the plain source code :) Cheers Raul Cheers Raul ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] unlimited clay - Arch questions
Hi all This weekend I have made several performance tests and the bottleneck are in this functions: make_editMesh() load_editMesh() free_editMesh() BLI_pbvh_build_mesh() those are the more time consuming parts I will try to move outside the make_editMesh() and free_editMesh() if I find a way to update the editMesh selection based on the mesh selected verts, that is, like in the Edit mode, when the object enters sculpt mode it could create the EditMesh structure, that will be updated in each step (and not created/deleted) I just need to translate the base mesh selected verts to the EditMesh verts. this step could save lot of time. The remaining bottleneck will be load_editMesh() , for update the base mesh from the editMesh, this step should be performed on each stroke, I don't know other variant to update the base mesh than this. Is there any? and the BLI_pbvh_build_mesh() that hopefully will be tractable thanks to Nicholas advices. And more important: is there a way to modify/update/add/remove the base mesh without call or construct an EditMesh? that way we could skip the load_editMesh() call and get an instant update and a big speed gain, if those conditions could be met I think we could achieve production ready speeds in realtime unlimited clay. thanks in advanceRaul ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] unlimited clay - Arch questions
Hi Nicholas :) > Hi, > > I think here neither the Mesh data structure nor EditMesh data > structure is exactly what you want. Exactly the structure that you do > want is a little harder to say of course :) Depends on how the mesh is > being subdivided by unlimited clay. > I was suspecting something like that ... you suggest as a modifier? I'm trying to reuse as much blender code as possible, that's why I choose EditMesh that has already aviable subdivission functions and more that will be matter of plug them in the code in order to work, I will give a last try to EditMesh to see how much performance gain I can pull of it , before trying other attemps. > Anyways, it occurs to me you might want to consider writing your own > DerivedMesh variant. Internal to your DerivedMesh, you can set up > whatever data structure you find most helpful to accelerate your > subdivision algorithm. Whenever the DerivedMesh is free'd, you can > write out the changes to the real Mesh. You can also extend the PBVH > with support for this new DerivedMesh type. > > The above is actually exactly how we do multires, which internally > uses a quite different representation than a regular Mesh. In this way > you can bypass editmesh entirely, while also avoiding hacking on your > own changes to Mesh, which from my own experience is a Bad Idea. :) > > -Nicholas In case I have to write a new structure, how it is updated/draw in the viewport? converting to Mesh? I hope no Thanks a lot Raul ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] meetings for new developers
Hi all :) I really like the idea about meettings for new devs, though I feel some envy because anything that smell to live, chat, internet is science fiction to me :) and that brings me the question about a strong offline support: What about a good offline reference, tutorials, even a book (ok, a downloadable pdf) something like a Blender Beginers Developer´s Guide? Is there a plan for it in the future? Investing resources in documentation is by no means a waste, and often something understimated in the open source world. Hey, a beautifull help documentation (for users and developers) is the best marketting resource of a software. The main drawback of a highly dynamic program like Blender is that the software evolve much faster than its documentation or the features/code/UI change a lot making learning materials rapidly obsolete but I guess it represent a defy full of oportunities and not a source of problems. If someone want to make a very special contribution to Blender and is not a developer I think this could be a good project, he even could specilized on Blender official documentation from now on. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Verlet integration patch (Farsthary)
Hi all :) Currently the particle system support 3 integrators types (in english integrators are what actually advance particles in space and time) and for many users that´s the kind of options that fall under the I-always-will-use-the-default-value category, and while for many set ups different integrators provide very similar results, in others they could make the difference. The simplest integrator, Euler, is very fast but not very accurate, internally Blender performs only one cycle of some calculations. The second integrator, Midpoint , is sligthly slower because it performs 2 cycles but is more accurate than Euler and is the default integrator. And the third , RK4 (Runge-Kutta) , as you may guess is the slowest and more accurate of them, and performs 4 cycles of calculations in Blender The good news here is that I have implemented another integrator type that is as fast as the Euler integrator (the fastest) since it requires only one cycle of calculations and is more accurate than the Midpoint even, the error is of fourth order: The Verlet integrator http://en.wikipedia.org/wiki/Verlet_integration#Basic_Verlet have several advantages over the others and is very stable , fast, and gives realistic results. this is the manual patch (is very small so will not cause any troubles patching Blender): http://www.pasteall.org/9292/diff Check my site: http://farsthary.wordpress.com for more details I have implemented it in Blender seamlessly and I suggest it as the default integrator, the previous integrators suffer from an increase of energy in time, note how the amplitude of each bounce is biger than the others in the previos integrators while in the Verlet is uniform as should behave in a conservative enviroment (no friction,damping,etc). Also for many particles interacting each others the Verlet integrator clearly shows its speed even compared with Euler. Is very easy to implement in Blender and is a small step toward improvement. Could some core dev review it for commit? Cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Verlet integration patch (Farsthary)
Hi Jahka :) > The overall idea looks nice, but the patch isn't complete. For example the > oldpos and diff vectors aren't declared anywhere and oldpos isn't even > defined in the patch. Besides isn't oldpos just pa->prev_state.loc? Ops! sorry, is that I have deleted manually some parts for better readability but seems I screw things :) I didn´t knew the full state of particles, that´s why I created those variables, but pa->prev_state.co works fine :) > I'd > also like to see vector macros used in the calculation like with the other > integration methods (you should always try to stick to the surrounding > code's style when poking around somebody else's code). Also I let the code without macros for readability also, but is corrected now > And while it's true that the error per timestep is fourth order (meaning > third order total accumulated error) for location, the error per timestep > for velocity (which you btw use to calculate the location) is second order > (first order total accumulated error!), so I'm not convinced it's better > than midpoint for all cases and without proper testing I can't yet comment > on making verlet the default integration method, but I'll be happy to > apply the patch once the couple of code issues I mentioned above are > fixed. The question about making it default can be addressed later. > > jahka I guess you should try it, the simples set up with particles is a colider ground with no friction/damping and particles with no drag/damping etc, a conservative enviroment, the midpont integrator (and the Euler and RK4) gives increasing bounces with time, not preserving particle energy, the Verlet integrator implemented here do conserve energy, and that is just the simples set up. Also try to test it with lost of particles interacting each other and you will notice and speed boost I have edited the patch and applied your suggested changes, Thanks a lot :) http://www.pasteall.org/9364/diff Of course, the default sugestion was just that, a suggestion and could be discussed later once performed several tests Cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GPU computing
Hi Ishan > Hi all, > > Let me start by thanking you all for the development of such a great > software. Blender has been a life saver for me many a time. Having said > that, I think Blender has a lot of scope for improvement, mainly on the > performance side. A lot of commercial software in 3D modeling, rendering, > video editing etc are starting to take advantage of GPU's computing > ability. > I think it is a great feature to add to Blender, and I would like to > contribute to it. Thanks for your words and thanks also for your attitude :) > However I am new to Blender source code. So I am looking for some > guidance. > Please give me suggestion on what API to use (CUDA/OpenCL), where do you > think GPU computing most (rendering, video processing, etc.) and any other > suggestions you may have. Thank you. > > Regards, > Ishan I would recomend OpenCL, since it aims to be hardware independent, not even just GPU but almost every piece of metal out there that could perform calculations :) , while CUDA is currently more mature than OpenCL is tied to NVIDIA brand :( And while is not an easy task what you propose I think the most needed are are: Rendering,Modeling,Compositing Regards Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GPU computing
Hi again Ishan I recommend you start with a very narrow project, even if you have lot of skills in GPU programming, from all of the proposed areas choose first the smaller/simpler one and go ahead, then if you succeed go for bigger shots. You will get here all sort of recomendations because virtually every part of a 3D app cry for paralellization, from rendering (the most representative), animation, nodes/compositor transcoding, to a neverending list. So gather strength in very tiny projects, even if they don't have a big user impact, your rate of success will skyrocketed. Cheers ___ 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
Hi :) +1 for me, my early experiments in unbiasing Render Internal with pathtracing, and also Final gathering clearly shows the limitations of the current shading system and prevent advaced rendering techniques and scalability without a bunch of hack. With the new proposal everything will be relatively trivial to implement. The PBRT book and the Luxrender project are excelent references also along with mantra. I have an especial question: I haven't see in the proposals the Sampler structure, wich should be the heart of the new pippeline, it provides the foundation of every aspect of it, from BxDFs (even for evaluating multilayered/compound BxDFs ), Integrators, ligths, texturing, camera, etc. Having the sampler independent from those components will allow the use of efficient/smart sampling strategies in the whole Render internal. Also as the render gain in complex features and phisically based ones, render times could increase and the cost of tweaks do the same for that reason I think the system should support flexible Deep Render Buffer (output and store not just RGBA values but any data structures/values) that way, for example, storing for each pixel the whole ray tree with surface normal/color values will allow at postprocessing interactivelly change the material/texture properties without rerender the scene. I would like to contribute to this development, so count on me, though with the heavy pieces of this chess in movement I don't think a pawn could do much :) All the best Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] New force type patch: Spring (Farsthary)
Hi all :) Searching to add spring forces for the fluid particles I end up with a nice patch that adds also spring force as a new general force type that could be used like any other blender force: for objects, particles, etc. Needless to say the importance and wide use cases for spring forces in 3D, previously this functionality was aviable in Blender only in softbodies,cloth and constraints but with this patch could be extended to particle systems for many SFX's and also to objects, te posibilities are endless :) Is interesting to note how the particle system integrate features from softbodies and fluids :) I will send thi spatch also to Jahka for review and commit Is very easy to implement and does not break any previous code, it only will need a new UI slider for spring rest length but I'm not good at UI coding, though it should be easy to add :) http://www.pasteall.org/9806/diff Hope you like it, cheers Farsthary :) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New force type patch: Spring (Farsthary)
Hi :) > This sounds really great. Could you give and example of how it might > be used for objects and what that might look like? I had the same > thoughts about it as a force. > Thanks! > In my site I have uploaded some examples with fluids that adds elastic behavior for them. http://farsthary.wordpress.com with sigle objects set to spring force you get that object extending springs to every afected particle, and with particles set to affect themselves with spring forces you get the typical N-body elastic behavior. This fill the gap between particles and softbody, allowing a wide range of interesting effects. > On Mon, Dec 14, 2009 at 7:55 PM, Raul Fernandez Hernandez > wrote: >> Hi all :) >> >> Searching to add spring forces for the fluid particles I end up with a >> nice patch that adds also spring force as a new general force type that >> could be used like any other blender force: for objects, particles, etc. >> Needless to say the importance and wide use cases for spring forces in >> 3D, >> previously this functionality was aviable in Blender only in >> softbodies,cloth and constraints but with this patch could be extended >> to >> particle systems for many SFX's and also to objects, te posibilities are >> endless :) >> Â Is interesting to note how the particle system integrate features from >> softbodies and fluids :) >> >> Â I will send thi spatch also to Jahka for review and commit >> >> Â Is very easy to implement and does not break any previous code, it >> only >> will need a new UI slider for spring rest length but I'm not good at UI >> coding, though it should be easy to add :) >> >> Â http://www.pasteall.org/9806/diff >> ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New force type patch: Spring (Farsthary)
Hi :) > Hi Raul , > hum .. still missing the point > to me it looks like a force field ( potential ) .. having a minimum > at R ( which you define as rest length ) Yes, that's the potential energy of the hook's force, there's nothing troublesome there :) > So.. > 1. what is the point in having a potential arranging a mesh close to a > S3 (sphere in 3D ) That was just a quick/useless set up to show the effect, that is not a real use case, a more real use case is the first video in my site, the simple.wmv where each particle extend springs to the rest, when you have tons of points pulling/pushing themselves around their relatives rest lengths interesting things happen and shapes arise, that bunch of points (particles, etc) became elastic :) Also, in the first useless example you could set the center not just the force object center but the objects vertices or every surface point and then you will get more complex behaviors, not only OSCILATING the mesh around an S3. > 2. the lack of other forces .. like friction to surrounding media .. > even internal friction .. makes it look quite. say .incomplete > but still > may be i am missing the very spot, enlighten me > BM This force perfectly interacts with the rest of the forces, and although adding velocity damping is not difficult at all I think is redundant since those effects could be achieved with the particle damping factor in the Newtonian panel. Think of it as a system and not as an isolated force, the rest of the system have drag forces,damp factors etc, so for complex behaviors like dampen springs you just set them also and there's no need to increase force complexity adding those alreday calculated therms to the force source code. (Againg, if there's some use cases that justify it in the force source code it will be a matter of minutes to add it) Cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New force type patch: Spring (Farsthary)
Hi BM > These features are in soft / cloth but handled in a context specific way. > I'd like to see them i a larger, more general framework. > For cloth ( hair is even worse ) i am not sure if it works since it > must use topological properties of the mesh for untangling and such, > but borders from viscous particle fluids to soft 'solids' are not > really there. ( Only depends on the spring structure inside ) > So it should be possible for soft bodies. Yes, the spring force for particle systems add softbody-like behavior but not hair-like/cloth-like because as you said it requires topological information that by its very definiton a particle system don't have and also is not needed. The spring force is juts another force type (like vortex, magnetic, wind, etc), a force type that have its use cases, is not an attemp of unification of the physics system, it just add elastic behavor to the particle system in a consistent and easy way. In theory a particle system could became everything and include all simulation effects (cloth,hair,softbody,fluids,smoke) and while having a general physisc framework is a desirable feature I don't think is feasible rigth now but that should not be an excuse to let the users waitin for those features. What we (Stephen,Jahka,me) are doing is adding those behaviors to the particle system: now spring forces that adds elastic/plastic softbody-like behavior and soon SPH particles that add fluid like behavior. Specialization vs generalization will always be an eternal debate and I think the best option is a mix of both. This patch add a simple spring force type, we are working also in a more softbody like model with dynamic arrays of springs that perhaps fulfill more the rigid/sorftbody target. :) > On the long run i can imagine the entire soft body module moving to there. > Though the mayor part of the soft body code deals with building up and > managing states of > complex spring structures with respect to ( vertex group ) painted > distributions of mass, spring constants and damping. > Accumulation of forces and solving differential equations is the far > smaller part :) > Beside it deals ( in pretty clumsy way ) with edge vs face collisions > which particles due to the vertex only nature > don't need, but would need for nice hair. As i said before hair is even > worse. Good hair needs collision and untangling of strands > -> definitely makes use of topological properties. > Still, that would be a very nice unification of the 'spread all over > physics' right now. > Don't know how that fits to the mesh modifiers then? Again, I don't think it will happen, while particle systems could feature sotbody behavior I think there always be cases where an especialized softbody implementation that could use the topological information of meshes is the best choice and in the case of clothes and hair is even less possible. But then again, I don't think is a necesity :) > I think damping along the spring direction is needed: > Think of a vertex orbiting around the centre an only radial components > decay. > (And yes i know it is a 3 liner, if the velocity of the vertex is > available) > For more complex meshes that would keep the motion of the entire object > but eating > 'inner' vibrations. Like a lava eruption from a planet with no > atmosphere and too small > to keep the lava blob in range via gravitation. While that could be achieved curretly simply increasing the particle damp value it will not harm then implementing velocity damping inside the spring force. > Finally i have to say: I am very impressed/pleased to see which > direction the 'physics thing' is taking and > like to be constructive, productive, helping .. when ever i can. > So don't take this as /ME rants 'will never work .. grumble' > but things i'd like to be thought of before making decisions. > BM It's OK :) , I preciate every feedback and I really thank you for taking your time and discuss this topics with me, your doubts could be the doubts of many and we all end up winning here ;) I still need the approval of Jahka to take some design decitions but if it gets in I could elaborate with more time an extensive documentation and tutorials about this feature, since a video tells more than words :) Cheers Raul (Farsthary) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Development plan proposal for after the 2.6 series
> Hi all, > > I'd like to propose that after the 2.6 series completes that we start > scheduling patch review and perhaps have a development focus. > > My thoughts were to have a 1 or 2 month rotating cycle where we focus > on one area of Blender and try and bring that area to be the industry > leader in terms of speed of workflow and capabilities. During that > time period I'd recommend we have a commitment to review all patches > that are relevant for that area - of course coders could review other > patches as well that are relevant to them, but with a schedule outside > coders can have a clear idea of what code base they need to have their > patch current against, and have a clear timeline about when they can > expect their code to be reviewed. Also with a schedule - artists can > have a clear timeframe to submit ideas and proposals and mockups. > > I'd recommend that we order the development similar to a production > pipeline (Ie similar to how Durians development timeline is ordered). > +1 on me, development focus is the only way to leverage the weak areas of Blender because as much as skilled/talented may be a dev he can't compete with a well organized team. If the UI/event system overhaul haven't being a dev focus it probably never happen so the big task should be accomplished with teams. But is also good to maintain the flexiblity because many good things has came to Blender outside the official projects and the priority schedule could became a discriminating factor , the 3d world is very dynamic and priorities changes from one year to the other. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Unifying Spring with Harmonic force (Farsthary)
Hi all :) Thanks to Jahka feedback where he told me that he suspected that the current harmonic force acts in a similar way that my spring implementations I have performed some research and he is rigth, just that the harmonic force don't consider a rest length parametter. So I have merged both implementation into one, the Harmonic force now use the Spring force code with rest length and reuse the previous Harmonic velocity damping. Now everything is ok, if the user set the rest length of the new Harmonic to 0 he will get the old harmonic behavior and if set its value to any other he will get the new Spring force nehavior. the new patch is at http://www.pasteall.org/9882/diff now it requires even less changes :) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Development plan proposal for after the 2.6 series
Hi > I think this plan could work, but only if the BF invested funds in >paying relevant developers for the duration of each cycle. I think >this is effectively what the open movie projects accomplish, without >the requirement that the new features must be tested in production of > >Joe Why not small Open Dev projects (one-two month cycle) similar to the Open Movie project but instead of focusing on a final movie investing funds in all the necesary machinery for that (which I consider is very effective for its goal) the output of such Open Dev projects could be a small but well elaborated features demo/documentation.? Just a pointless thougth ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] killer feature: multifluid interactions for fluid particles done! (Farsthary)
Hi all :) Fluid - Fluid interactions or Multifluids interactions are responsible for a wide range of effects and events in nature and heavily used in the CG insdustry. While the Elbeem fluid simulator integrated in Blender is pretty powerfull is designed for single fluid simulations (I mean, you can't mix oil with water in it for example) but in SPH particles that is no longer an issue :) and if that where achieved it will automatically became a huge feature for the fluid particles :) So as my christmas present for the whole Blender community I have implemented full multifluid interactions for the fluid particles in Blender! you can mix any number and any fluid types!! (hardware provided ;) ) I have sended Lapinou the videos for posting soon in my site, so check it regularly: http://farsthary.wordpress.com I show there three videos, one where two fluids, red and blue, get fully mixed, one with those get partially mixed and finally one with two fluids that don't mix each other and form the well known fluid-fluid interface or boudary. I'm very exited about it :) So far, fluid particles are almost ready and feature near complete in the simulation side (after official commit we still add dynamic spring arrays for shape gloas and rigid body like behavior), so now the main issue remains the surface generation that will be tackled soon. After that Stephen and I will send a patch to Jahka for review. Have a nice christmas Raul Fernandez (Farsthary) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Sticky particles (or sticky surfaces) patch (Farsthary)
Hi all :) The good news continue arriving :) I have added yesterday a stickness factor to the particle collider objects, this will allow more interesting effects as I will post soon in my site, like wet surfaces, etc. Coding it as a property of the collider object and not of the particles will allow to set up scenes with different colliders that respond diferently to the same particle system. the patch is at: http://www.pasteall.org/10045/diff Is very easy to commit as it will require few lines of code but the benefits are enormous, it works with all particle physics types and especially well with the upcomming Fluid particles. Hope you like :) Raul Fernandez ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Multiple Ligth Scattering buggs correction (Farsthary)
Hi all :) Congratullations and Happy New Year! I spend the whole day yesterday fixing old buggs in the volumetric code regarding Multiple Ligth Scattering since it was not behaving as should do. I also have made a few performance improvements to the code, like for example, in many places where appears multiple calls to the indexing functions V_I() in the same scope , calculating it once and stored in a variable and then call it when needed, it saves some multiplications :) I have sended the patch to Matt Ebb for review and commit, it should not be very difficult to apply, in case someone want to take a look at it I attach it at the end of this mail. Here's a summary of the squashed buggs ;) : - they where a non correspondence between the LC and the MLS buffers, they follow a different alligment that lead to incorrect fill process if use a single indexing function for both. (I have corrected the indexing in the MLS buffers) - The actual diffussion process where something like ... x[]=x0[]+a(x[]+x[]+...)/(1+6*a) where should be x[]=x0[]+a(x0[]+x0[]+...)/(1+6*a) each simulation step is only dependant on previous step or buffer. - The MLS buffer where not initialized and filled with the single scattering pass before the actual simulation start, in the shade_one_lamp() only the single scattering trigger the LC calculation, where should be triggered also in the Multiple scattering and the shaded+Multiple scattering cases. The MLS should start from the single scattering filled ligth cache. - the Multiple scattering was called after the filtering function calls where should be called BEFORE, because the filtering function may introduce artifacts that later will get amplified in the MLS simulation process. And finally, this is not a bug but a correction: the diffussion parametter is in range 0.0 to FLOAT_MAX , where it only have sense in the range 0.0-1.0, higher values than 1.0 have no effect,does not increase the diffussion: in file rna_material.c prop= RNA_def_property(srna, "ms_diffusion", PROP_FLOAT, PROP_NONE); RNA_def_property_float_sdna(prop, NULL, "ms_diff"); -- RNA_def_property_range(prop, 0.0f, FLT_MAX); ++ RNA_def_property_range(prop, 0.0f, 1.0f); RNA_def_property_ui_text(prop, "Diffusion", "Diffusion factor, the strength of the blurring effect"); RNA_def_property_update(prop, 0, "rna_Material_update"); --- here's the complete diff patch -- diff -r /home/raul/Escritorio/Previous/volume_precache.c /home/raul/Escritorio/Modified/volume_precache.c 24c24 < * Contributor(s): Matt Ebb. --- > * Contributor(s): Matt Ebb, Raúl Fernández Hernández (Farsthary). 137,139c137,139 < < if (cache[ V_I(x_, y_, z_, res) ] > 0.0f) { < tot += cache[ V_I(x_, y_, z_, res) ]; --- > int i= V_I(x_, y_, z_, > res) ; > if (cache[i] > 0.0f) { > tot += cache[i]; 167,172c167,173 < if (vp->data_r[ V_I(x, y, z, vp->res) ] < -0.f) < vp->data_r[ V_I(x, y, z, vp->res) ] = get_avg_surrounds(vp->data_r, vp->res, x, y, z); < if (vp->data_g[ V_I(x, y, z, vp->res) ] < -0.f) < vp->data_g[ V_I(x, y, z, vp->res) ] = get_avg_surrounds(vp->data_g, vp->res, x, y, z); < if (vp->data_b[ V_I(x, y, z, vp->res) ] < -0.f) < vp->data_b[ V_I(x, y, z, vp->res) ] = get_avg_surrounds(vp->data_b, vp->res, x, y, z); --- > int i= V_I(x, y, z, vp->res); > if (vp->data_r[i] < -0.f) > vp->data_r[i] = > get_avg_surrounds(vp->data_r, vp->res, x, y, z); > if (vp->data_g[i] < -0.f) > vp->data_g[i] = > get_avg_surrounds(vp->data_g, vp->res, x, y, z); > if (vp->data_b[i] < -0.f) > vp->data_b[i] = > get_avg_surrounds(vp->data_b, vp->res, x, y, z); 175c176 < } --- > } 181c182 < int x, y, z; --- > int x, y, z; 197,202c198,204 < if (vp->data_r[ V_I(x, y, z, vp->res) ] < -0.f) < new_r[ V_I(x, y, z, vp->res) ] = get_avg_surrounds(vp->data_r, vp->res, x, y, z); < if (vp->data_g[ V_I(x, y, z, vp->res) ] < -0.f) < new_g[ V_I(x, y, z, vp->res) ] = get_avg_surrounds(vp->data_g, vp->res, x, y, z); < if (vp->data_b[ V_I(x, y, z, vp->res) ] < -0.f)
Re: [Bf-committers] Shading System Proposals
Hi :) > Also, in my experience, letting the BSDF compute the wo must be done with > care. It is not a good idea to let the BSDF have its own independent > sample > generator. If two different BSDF sample generators are corelated for > several > consecutive paths, this can (and generally will) produce moiré or lisajou > or > caustics artifacts. That's what I was refering when I said that especial care should be put in the design of a good sampler, it is the heart of every Monte Carlo algorithm and could not be substitute with combination of RNG functions. > A strategy that works well is to use a > multiple-dimensional sampler per path and you need as many (times 2) > dimensions as there are bounces in your path. Each bounce requires 2 more > dimensions. For example you need dimension 1 and 2 to sample the light > surface and 3, 4 to sample the direction from the light surface. Then you > would need dimensions 5,6 to sample the bounce direction from the BSDF on > the hit point, etc. Sobol sampler can do that by using different prime > numbers for every dimension. This strategy can be hard coded in the BSDF > but > it would be more flexible in allowing someone to develop different path > sampling strategies if another sample() function could take u and v > parameters and use those with a warp function to sample the distribution. > >> * intensity estimate: given in vector (or not)?, integral over >> outgoing directions A global sampler must be set, a multidimensional one like PBRT does, that way every aspect of the shading system could take advantage of better sampling strategies, the sampler itself could be a node that provides samples to every other node that need it. Firstly keep it simple, one or two simple sampling algorithm but later, once the system is functional more strategies could be easily and independently added. Regards Raul ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] fire simulation
Hi Lukas +1 I found very interesting your proposal and while the current simulator and volumetric rendering could achieve very cool fire effects I think a dedicated simulator will be much more artist friendly and usefull, so go ahead! is a very nice project. Cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Particle diffussion or mixing fluid properties
Hi all :) Previously, when I show the mixing fluids feature of fluid particles I only sowed the physical behavior of the mixing fluids and as was pointed by Daniel Genrich , it still missed mixing mixable fluids or diffusion. Well, the good news is that properties diffussion is pretty straigthfoward to add, not just color could be diffussed among mixable fluids but just everything (temperature, etc) and as a proof of concept I have implemented color diffussion :) Currently is only at viewport level (OpenGL level) and I need to thinker more on it to make it usable for end users , but is a nice insigth of what will come in the future :) for some screenshots and a video visit my blog: http://farsthary.wordpress.com cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers