Re: [Bf-committers] Hair settings suggestion - Hair density setting instead of fixed Amount of hair particles
This is a very nice idea, I'll put it on my particles todo-list :) On Wed, 13 Apr 2011 23:01:23 +0300, Damir Prebeg wrote: > Well, I'm not a programmer so I don't know how hard would that be for > implement, but I think that some kind of hair density option instead > of current overall amount of particles would be much better option for > hair system. For instance Number of hairs per square BU or something > like that. That way when I resize hair emitter, I wouldn't have to > touch hair settings. > ___ > 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] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [35896] trunk/blender/release/scripts/ startup/bl_operators: Quick effects operators:
On Wed, 30 Mar 2011 15:06:18 +0300, Carsten Wartmann wrote: > Am 30.03.2011 12:29, schrieb Janne Karhu: >> Revision: 35896 >> >> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=35896 >> Author: jhk >> Date: 2011-03-30 10:29:32 + (Wed, 30 Mar 2011) >> Log Message: >> --- >> Quick effects operators: >> * A couple of operators to quickly create effects that would otherwise >> take some time to set up. >> * Nice to use for demoing functionality or as a starting point for more >> complex effects. >> * "Make Fur" - Gives every selected mesh object particle fur with a >> desired density and length. > > Some generic Material would be nice. ;-) Added a generic fur material! > >> * "Make Smoke" - Makes each selected object a smoke emitter and creates >> a new domain object around the emitters with the correct material to >> render the smoke. > > I think the domain should be rotated not following the view direction > but global. Yes if would be very nice to be able to rotate the domain, but rendering smoke with a rotated domain is not really working like it should, so for now globally aligned domains it is :) > >> * "Make Fluid" - Makes every selected object a fluid object >> (normal/inflow) and has the option to start fluid baking immediately. > > Could not get it to work, physics are created but baking shown nothing. Are you sure? For me checking the "start baking" will start a fluid baking job just fine (this can be seen in the top header). You'll have to manually step through the timeline to see the results as they're being baked. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [35755] trunk/blender/source/blender/ editors/physics/physics_fluid.c: Further fix for parented fluidsim objects
Oh, thanks for the tip! I always thought it didn't correct for +-360
degrees, but looks like it does, great!
On Thu, 24 Mar 2011 23:51:29 +0200, Campbell Barton
wrote:
> mat4_to_compatible_eulO should be able to do this (rather then own
> function continuous_rotation).
>
> On Thu, Mar 24, 2011 at 5:15 PM, Janne Karhu wrote:
>> Revision: 35755
>>
>>
>> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=35755
>> Author: jhk
>> Date: 2011-03-24 17:15:43 + (Thu, 24 Mar 2011)
>> Log Message:
>> ---
>> Further fix for parented fluidsim objects
>> * The rotation values determined from ob->obmat have to be continuous
>> as fluidsim interpolates between these values internally.
>>
>> Modified Paths:
>> --
>>trunk/blender/source/blender/editors/physics/physics_fluid.c
>>
>> Modified: trunk/blender/source/blender/editors/physics/physics_fluid.c
>> ===
>> --- trunk/blender/source/blender/editors/physics/physics_fluid.c
>> 2011-03-24 14:31:58 UTC (rev 35754)
>> +++ trunk/blender/source/blender/editors/physics/physics_fluid.c
>> 2011-03-24 17:15:43 UTC (rev 35755)
>> @@ -349,6 +349,16 @@
>>}
>> }
>>
>> +static void continuous_rotation(float *rot, const float *old_rot)
>> +{
>> + *rot += (int)(*old_rot/360.f)*360.f;
>> +
>> + if(*old_rot - *rot > 180.f)
>> + *rot += 360.f;
>> + else if(*old_rot - *rot < -180.f)
>> + *rot -= 360.f;
>> +}
>> +
>> static void fluid_init_all_channels(bContext *C, Object
>> *UNUSED(fsDomain), FluidsimSettings *domainSettings, FluidAnimChannels
>> *channels, ListBase *fobjects)
>> {
>>Scene *scene = CTX_data_scene(C);
>> @@ -451,8 +461,14 @@
>>/* init euler rotation values and convert to
>> elbeem format */
>>/* get the rotation from ob->obmat rather than
>> ob->rot to account for parent animations */
>>mat4_to_eul(rot_d, ob->obmat);
>> - mul_v3_fl(rot_d, 180.f/M_PI);
>> - sub_v3_v3v3(rot_d, rot_360, rot_d);
>> + mul_v3_fl(rot_d, -180.f/M_PI);
>> + if(i) {
>> + /* the rotation values have to be
>> continuous, so compare with previous rotation and adjust accordingly */
>> + /* note: the unfortunate side effect of
>> this is that it filters out rotations of over 180 degrees/frame */
>> + continuous_rotation(rot_d,
>> fobj->Rotation + 4*(i-1));
>> + continuous_rotation(rot_d+1,
>> fobj->Rotation + 4*(i-1)+1);
>> + continuous_rotation(rot_d+2,
>> fobj->Rotation + 4*(i-1)+2);
>> + }
>>
>>set_channel(fobj->Translation, timeAtFrame,
>> ob->loc, i, CHANNEL_VEC);
>>set_channel(fobj->Rotation, timeAtFrame, rot_d,
>> i, CHANNEL_VEC);
>>
>> ___
>> Bf-blender-cvs mailing list
>> bf-blender-...@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-blender-cvs
>>
>
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Fluid particles refactoring
On Mon, 21 Feb 2011 04:53:46 +0200, Alex Fraser wrote: > We have been using the SPH solver for engineering simulations. In our > experiments, we often vary the fluid interaction radius independently > from the collision radius. For example, if the size of a hole in a > container mesh changes, I might want to make the collision radius > smaller. Then again, it might make sense to make the interaction radius > smaller too, so that the particles still flow nicely through the hole. > > I suppose what I really want to do is change the resolution of the > simulation without drastically changing the way the fluid behaves (e.g. > double the number of particles, but maintain the same volume). If you > can acheive this by changing the rest density at the same time as the > interaction radius, I'm all for it. Will there be a way to find out what > the interaction radius is, for the sake of writing reports? Also, what > will the Advanced > Rest Length setting do? Partly thanks to your comments and some other people I've slightly changed my plan now and I do intend to include an interaction radius parameter in the advanced section. However I'll also add an additional setting to "multiply interaction radius with particle size", pretty much like the current setting to "multiply mass with size". By default this option will be on, so that it's easy and intuitive to start, but if you want to do it the old way then that will be possible too. In my current code the interaction radius is 4.0*particle size, which seems to give quite natural results (this will include nearest neighbors at distance 2*size and just barely the next ones at distance 4*size in the sph calculation). The spring rest length is 2.0*particle size, and the advanced "rest length" parameter is just a multiplier for that default length. > > One big challenge for us has been finding out how the parameters > presented in the UI relate to physical quantities. The information > doesn't seem to be available in the paper the Blender SPH code is based > on: > > http://www.iro.umontreal.ca/labs/infographie/papers/Clavet-2005-PVFS/ > > Perhaps the simulation in Blender is unphysical. We intend to implement > a classical SPH algorithm, i.e. one without the double density > relaxation, to perform further experiments with. We expect it will be > more physically accurate (although perhaps lacking surface tension), and > easier to make multi-threaded. Yes the whole approach taken in the paper is pretty unphysical (or at least not at all concerned with the physical quantities of fluids) and I think in a sense that's good as it's designed to be nice system to play with without having to check physical values from somewhere. Of course it would also be nice to be able to do physically correct simulations, and hopefully the changes I'll make will make it a bit easier to test other sph implementations too. janne ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Fluid particles refactoring
On Sat, 19 Feb 2011 00:57:39 +0200, Michael Fox wrote: > i don't like how size is now being used as ui tend to use "size deflect" > with some random size which means if i increase the size, hence the > radius then the particles will float above the collision object. I've used size deflect in pretty much all my fluid tests and using particle size to influence the interaction radius too only seems natural to me. Perhaps I didn't make it clear enough that the idea is not to have interaction radius = particle size, but that the size defines a sensible radius so that enough neighbors are included in the calculations (for example 4 * size). So I don't quite get how this would make the particles float above the surface.. but can you please explain your work flow a bit more so I can understand the problem? On Sat, 19 Feb 2011 01:11:28 +0200, Carsten Wartmann wrote: > BTW: Is there a documentation in one place for all the new particles? > Even in your blog it is hard to keep track. Yes the existing documentation is quite outdated. Once I get these changes ready I'll make a proper tutorial or perhaps even a couple on how to use the fluids in different cases, so that will hopefully help to get you started. >> And yes I do know that this will break old simulations, and that you >> book >> writers have to do some pages all over again, but my sincere intention >> is >> a better user experience with the particle fluids, so please forgive me. > > See above ;-) Beside us writers I don't think there is much use of them > at the moment beside self contained demos and some effects, so I think > it is acceptable to break some old simulations. This is very nice to hear :) And yes like Raul said surfacing is being worked on by him and Stephen, so hopefully we'll have some really usable fluid particles before the 2.6 is out! :) janne ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Fluid particles refactoring
I've been refactoring the fluid particles recently, and before I actually start getting ready to commit this I'd like to get some feedback on my current progress and ideas. http://code.blender.org/index.php/2011/02/particle-fluids-refactoring-under-way/ And yes I do know that this will break old simulations, and that you book writers have to do some pages all over again, but my sincere intention is a better user experience with the particle fluids, so please forgive me. I'll gladly read and respond to feedback either here or in the post comments! janne ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34720] trunk/blender: Texture context selector for texture panel:
Carsten: Yes I understand the frustration of a constantly changing ui very well, but bringing back the old behavior was what I was after too. I'll change it tomorrow so that switching from a possible texture owner panel to the texture panel works like before. The user preference to keep the context selector "pinned" can be added at a later time if it's needed. Daniel: This has been an age old problem in Blender and I think it will need some more thought before implementing anything. I don't think editing of unlinked data has ever been possible in Blender, so I'm not sure if direct access to unlinked stuff is really the best option. However I don't really see any obstacles to for example adding more contexts to the selector for modifier/node/etc. textures (I'm nearly done with particle textures for example and this will be added to the selector soon). janne On Tue, 08 Feb 2011 23:08:33 +0200, Carsten Wartmann wrote: > Am 08.02.2011 21:22, schrieb Janne Karhu: >> Carsten: The placement of the actual context menu is still under >> debate. I >> originally had the menu in the old location of the "brush" button, but > > ... > >> I also think both behaviors (context by selecting "parent" first vs. >> explicit selection via the new selector) are useful, so this could >> perhaps >> become a user preference. > > I apreciate your effort and works very much, but please keep in mind > that we are in a late beta phase please don't change much now, the > autors of already written or "just before relase" books will be very > thankfull. > > Development is a key to blenders success but also to have good > documentation which a (professinal) user can rely on. In this context is > is I think more acceptable to have a "not optimally" working but > documented solution rather than a well working which is no where > described or even worse which is not working like described. I.e. I > wrote at several places: "switch directly from the world context to the > texture context, add a texture..." which will now NOT work anymore, but > add a material texture. > > Hope you get my point. > > Carsten On Tue, 08 Feb 2011 22:31:32 +0200, Daniel Salazar - 3Developer.com wrote: > Ok but texture datablocks are used in more places, for example > modifiers like displacement, particle systems or individually in > shader node trees, in all this cases you need to create a temporal > material slot just to access the texture.. we need to be able to > create and access unrelated textures > > cheers > > Daniel Salazar > www.3developer.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34720] trunk/blender: Texture context selector for texture panel:
Carsten: The placement of the actual context menu is still under debate. I originally had the menu in the old location of the "brush" button, but this doesn't really feel intuitive as the context really defines everything that's shown in the panel. One option could be to position it as a one icon width vertical menu between the "pin" button and the context path to make it clear it's the "top level" choice. I also think both behaviors (context by selecting "parent" first vs. explicit selection via the new selector) are useful, so this could perhaps become a user preference. Doug: Changing the menu ordering for more consistency is a good idea indeed. janne On Tue, 08 Feb 2011 17:36:42 +0200, Doug Hammond wrote: > A couple of small thing to note: the world context button should be on > the > left of the material context button to match the order in the button row > above. > Also, I thought the buttons were perhaps a bit small, I didn't see them > at > all to start with. > > Cheers, > Doug. > > > On 8 February 2011 15:24, Carsten Wartmann wrote: > >> Am 08.02.2011 15:29, schrieb Janne Karhu: >> > Revision: 34720 >> > >> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=34720 >> > Author: jhk >> > Date: 2011-02-08 14:29:48 + (Tue, 08 Feb 2011) >> > Log Message: >> > --- >> > Texture context selector for texture panel: >> > * Texture context was previously determined by going to the >> appropriate >> panel, for example "world panel -> texture panel" to access world >> textures. >> Additionally there was a separate button to access brush textures. >> > * Now the texture context can be selected directly through an expanded >> icon menu, which shows the available context options. >> > * This context selector is now at the top of the texture panel, but >> this >> could later be perhaps integrated to the context path somehow to be more >> intuitive. >> >> Great, that will help to avoid many confusion. Of course I again have >> to change things in my tuts but well... >> >> One request: Could the old behaviour still work (for 2.5x at least)? So >> when changing from world context to textures it will choose world >> textures etc. This will keep compatibility with already written >> tutorials and books. >> >> Also the placement is a bit cluttered, for now I think it would fit for >> now where the old "Brush" button was. >> >> Carsten >> -- >> Carsten Wartmann: Autor - Dozent - 3D - Grafik >> Homepage: http://blenderbuch.de/ >> Das Blender-Buch: http://blenderbuch.de/redirect.html >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Bugtracker Question
Already reopened, but for the future commenting on the closed report will do just fine. janne On Tue, 16 Nov 2010 22:00:04 +0200, Remo Pini wrote: > Hi all > > If I think a bug has been closed in error (#23820), is there a way to > have it reopened? > > Cheers > > Remo > > ___ > 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] Developer meeting minutes, 14 nov 2010
Yes I agree pretty much fully on what you've written. The whole particle system is still really quite crippled from the jump from 2.49 to 2.5 and I haven't even wanted to start reimplementing certain features over (such as effecting particle properties with particle time and reactor particles), since I want them to become much more powerful than they were before. I too have high hopes for the node particles, but my proposal doesn't really change anything functionally for better or worse. It only give the users a bit more clarity on what the function of the "particle system" entry in the modifier stack is. I think this "clarity" will be needed even more for node particles, but even now you really want to be able to decide what point in the object's modifier stack is used for particles and other effects, no matter how the actual effects are calculated. jahka On Mon, 15 Nov 2010 05:38:25 +0200, Daniel Salazar - 3Developer.com wrote: > @jahka: I'm sure you know everything I'm about to say. Also this is of > course my personal opinion. > > Modifiers are limiting, as you know a much better design is going on > on luka's branch, it's flexible enough to handle any kind of data, > call it verts, particles, faces, etc. and let's you work with low > level data as easily as with high complexity tools. Current modifier > stack design is unreliable since the relationship between different > objects with modifiers is fixed and undefined. This would be clear and > manageable in a node environment. > > A worst scenario is the particle system. Personally I find it easier > and safer to code particle or object level effects in python from > scratch than taking the *risk* of using the particle system and > suddenly just hitting a limit in the design that won't let me do what > I need. I feel like I'm not in control. What I'm saying is that any > effect related feature is useless(?) if you can't tweak it/modify it > to do the exact thing you are asked to do. As long as the system > remains rigid in this sense every feature added feels so vain to me. > > I've placed my hope and interest in the node tree, it's already so > close to being immediately useful but also exponentially powerful when > it starts to merge currently separated systems into one unified > environment where data can be passed around and converted from one > type to another. > > > Daniel Salazar > > > On Sun, Nov 14, 2010 at 10:22 AM, Ton Roosendaal wrote: >> Hi all, >> >> Short meeting todo, here the relevant notes: >> >> 1) Current projects >> >> Particle UI, Janne proposes to better organize Particle modifiers: >> http://wiki.blender.org/index.php/User:Jhk#Modifier_Stack_proposal >> >> 2) Blender 2.5x issues >> >> - Bugfixing continues with full attention! >> >> - Ton will do bug 'triage" and assign to developers. Developers who >> have time please notify him. >> >> - If you have bugs assigned, but you can't work on it for a period (2 >> months?), please find someone else or un-assign yourself. >> >> - Wiki official maintainers list will be updated this week to get >> formalized, will also help assigning reports, and cleaning up the long >> list of svn committers (inactive devs will get removed). >> >> - Nathan Letwory will work on updating development wiki this week >> >> >> -Ton- >> >> >> Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org >> Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands >> >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Gravity under Smoke does opposite than tooltip says
The density of the flow object defines the initial density of the smoke that's created (from each particle). The new density (previously "gravity") setting of the domain defines how much the current density at any point of the smoke effects upwards force at that point. Similarly the flow object gives the smoke some initial heat (which changes during the simulation), and the "heat" setting of the domain defines how much the heat difference to the ambient temperature effects the upwards force of the smoke at that point. janne On Mon, 08 Nov 2010 13:26:20 +0200, Damir Prebeg wrote: > When you say "..how much the density..." do you mean on Density setting > on > Flow object? > > Regarding parameter name, Gravity could be called Smoke Weight or > something > similar... > > On 8 November 2010 12:09, Janne Karhu wrote: > >> Hmm, indeed this is not very logical. The "gravity" and "heat" >> parameters >> actually change how much the density and heat of the smoke effect the >> motion of the smoke, so they're not directly connected to gravity. I'll >> change the parameter name and add a bit more descriptive tooltips to >> both >> of the parameters. >> >> janne >> >> On Mon, 08 Nov 2010 10:54:36 +0200, Damir Prebeg >> >> wrote: >> >> > Don't know should I post this as a bug or this is just typing error? >> > Tooltip >> > says >> > "Higher value results in sinking smoke" but setting it self does >> exactly >> > opposite. >> > >> > But on the side of that, why gravity setting of Smoke system isn't >> > consistent with scene gravity? >> > I mean, min/max value of smoke gravity is -+5.0 and a default setting >> is >> > -0.0010. >> > Shouldn't that bee -+ 200 and default value -9.81? >> > ___ >> > 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] Gravity under Smoke does opposite than tooltip says
Hmm, indeed this is not very logical. The "gravity" and "heat" parameters actually change how much the density and heat of the smoke effect the motion of the smoke, so they're not directly connected to gravity. I'll change the parameter name and add a bit more descriptive tooltips to both of the parameters. janne On Mon, 08 Nov 2010 10:54:36 +0200, Damir Prebeg wrote: > Don't know should I post this as a bug or this is just typing error? > Tooltip > says > "Higher value results in sinking smoke" but setting it self does exactly > opposite. > > But on the side of that, why gravity setting of Smoke system isn't > consistent with scene gravity? > I mean, min/max value of smoke gravity is -+5.0 and a default setting is > -0.0010. > Shouldn't that bee -+ 200 and default value -9.81? > ___ > 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] IPO curves mapped to particles life.
This is not currently possible in 2.5 as it was a part of the old ipo system and I haven't yet reimplemented the functionality. The reason I haven't yet reimplemented it that I think the possibilities are far greater than just changing parameters in global vs local time, but I haven't yet had the time to figure things out fully. Rest assured the feature will be back (hopefully better than before) at some point. jahka On Tue, 11 May 2010 18:22:22 +0300, malefico wrote: > Hi all, > > In 2.4x, you could animate the material of a particle, let's say, Halo > Size, Alpha, etc, and this was mapped to the particle life. So if you > animate from frame 1 to 100, you would have that range mapped into the > particle life. This is great to make particles fade out when they are > about to die, etc. > > Now I have tried to do the same in 2.5 but so far I had no success. Old > settings just don't work, the material animation is mapped to global > time, regardless of the particle's life. Is there a way to make this > work ? or is it a current limitation of animation system ? > > Here's a sample file: http://dl.dropbox.com/u/3217451/gotas.blend > > Render it in 2.49 and 2.50 and see how differently it works. > > Thanks in advance ! > > malefico. > ___ > 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] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [27986] trunk/blender: Fluid physics for particles by Raul Fernandez Hernandez (Farsthary) and Stephen Swhitehorn:
The whole commit is quite self contained and won't break anything. Like I wrote in the commit message this commit is only the core physics so it doesn't really touch anything that could cause problems. janne On Sun, 04 Apr 2010 15:49:08 +0300, Matt Ebb wrote: > On Sun, Apr 4, 2010 at 10:29 PM, Janne Karhu wrote: >> Log Message: >> --- >> Fluid physics for particles by Raul Fernandez Hernandez (Farsthary) and >> Stephen Swhitehorn: > > Hi, this is interesting stuff, curious to take a look at it. How much > likelihood is there of this disturbing things though? I was under the > impression we were in a semi-freeze now, avoiding committing any large > changes in order to stabilise what's in SVN now. Anyway, maybe the way > this fits into the particle system doesn't introduce much potential > for breakage - if so, that's great. Otherwise I would personally > really prefer to to see any major developments/changes done in > branches for the time being. > > cheers, > > Matt > ___ > 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] fire sim update and design question
On Wed, 10 Feb 2010 11:15:27 +0200, Lukas Tönne wrote: > Either way it's very ugly and imo a problem with the current particle > system design (before you start shouting, i know particles will be > redesigned some time and there are more important things atm, so this > is just a theoretical question). How about this: Instead using one > object as the owner of the particle system and it's (only!) emitter at > the same time, wouldn't it be better to have particle systems as a > distinct object type (like mesh, light, etc.) and have a list of > objects, which function as emitters for this particle system? Not that > i would want to implement this right now, i would just like hear an > opinion on this (Jahka?). I've been playing with the idea of having particles separated from emitter objects for quite some time. I don't think making particles it's own object type is the right choice, but this could work very well by having particle systems defined in empties (hair should probably remain directly connected to the emitter though). This would allow for nice logical grouping of particle systems in different empties and allow for direct moving of the particles once they're baked by just moving the empty. The emitter object (or even a list of objects) for a particle system could then just be set as a parameter to the system. This would also be a small step in the direction towards node based particles codewise as it would separate particles from the emitter data. So while I don't have the time right now to start this project it's definitely something I'd like to pursue when I have the time. jahka ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [25499] trunk/blender: * Rest length parameter for harmonic force springs.
Apparently tortoise svn doesn't like accented characters so a proper credit about the patch to: Raul Fernandez Hernandez (farsthary). jahka ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Verlet integration patch (Farsthary)
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? 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). 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 On Sat, 21 Nov 2009 20:02:37 +0200, Raul Fernandez Hernandez wrote: > 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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
