[Bf-committers] transform() and particles!

[Ton Roosendaal]

Hi,

The GKEY-ESC combo is currently (ab)used for providing a way to get  
your particle system recalculated... not very nice, but its sorta  
standard & documented behaviour in Blender.

Adding this patch is possible though (we can define GKEY-ENTER for  
recalc!) but its not the real solution we should look for. The particle  
system just could become far more interactive in general, as for  
example being demonstrated during the Blender conf with Lightwave.  
Possible improvements;

- make an option to calculate particle systems "adaptive", meaning it  
can:
   - update specific keys only (the ones currently visible and needed)
   - lower the amount of 'interactive visible' particles based on  
realtime interactivity
   - and/or have two settings for particles, "render" and "display"  
totals.
- alternative; make a non-key mode which only calculates particle  
advances per frame
- then particles can even be put in a continuous playback mode, only  
updating keys (or positions) for particles per frame when needed, and  
allowing to change button values and seeing immediately what the  
results are.

The issue we have is just the backwards convention that it requires to  
calculate the full particle system before even drawing a single frame.

-Ton-


On 8 Jan, 2005, at 2:21, Matthew H. Plough wrote:

> Hi everybody --
>
> I just started playing around with the excellent particle deflection  
> tools.  I noticed something that annoyed me quite a bit, though -- I  
> get angry when canceling an operation takes a ridiculously long time.
> Here's the issue: Let's say that I select my particle emitter with a  
> huge number of particles to edit the particle system.  I inadvertently  
> press G or some other key, and start moving the thing around.   
> Instinctively, I hit Escape a bunch of times to cancel the operation.   
> However, up comes the timeglass cursor, indicating that it's time to  
> ponder what, if anything, happened with the particle system.  I don't  
> want to wait for the system to do absolutely nothing.  3d studio max  
> does that frequently, which drove me up the wall.  Having Blender do  
> the same thing would make me go bonkers.
>
> ...and now my solution:  It seems that special_aftertrans_update (in  
> editobject.c) doesn't bother to check if an operation has been  
> canceled.  It only checks to see if a mesh has a particle system  
> associated with it, and if it does, it recalculates.  Adding about 15  
> bytes of code to check if the operation was canceled fixes the  
> problem.
> The patch is attached.
>
> Matt
> Index: source/blender/src/editobject.c
> ===================================================================
> RCS file: /cvsroot/bf-blender/blender/source/blender/src/editobject.c,v
> retrieving revision 1.156
> diff -u -r1.156 editobject.c
> --- source/blender/src/editobject.c	29 Dec 2004 20:44:54 -0000	1.156
> +++ source/blender/src/editobject.c	8 Jan 2005 01:15:38 -0000
> @@ -4429,7 +4429,7 @@
>  					mb= ob->data;
>  					if(mb->flag != MB_UPDATE_ALWAYS || G.obedit == NULL)  
> makeDispList(ob);
>  				}
> -				if( give_parteff(ob) ) build_particle_system(ob);
> +				if( give_parteff(ob) && !canceled) build_particle_system(ob);
>  			}
>  			if(base->flag & BA_DO_IPO) redrawipo= 1;
>  			
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton at blender.org  
http://www.blender.org