[Bf-committers] Particle questions

[Toni Alatalo]

On Wednesday 16 November 2005 11:06, Ton Roosendaal wrote:
> Object.addParticleSystem()
> particles = Object.getParticleSystem()
> particles.VelocityNormal(value)

i posted similar draft to bf-python the other day, 
http://projects.blender.org/pipermail/bf-python/2005-November/003298.html

> - Particles is an Object method, like Object.Particles.AddNew() or

.. with the remark that in a way for a particle system there is not only one 
object, but potentially also other objects that affect: e.g. guide curves 
that currently define the fields.

as mentioned on that mail to bf-python, the Orange guys told that currently 
layers are 'abused' to define which guides affect which particle system (e.g. 
which curves shape which hair). they figured it'd be better for layers not be 
used for that kind of things, but more for just controlling visibility etc.

so that'd say that it would make sense to actually connect the guides to the 
particle systems, instead of having them as forces 'in the air'. and in that 
case the object could be just be one of the objects that define the particle 
system, called e.g. emitter?, and the particle systems would be objects on 
their own.. a paste from the bf-python post with some comments added:

p = ParticleSystem() #a new particle system, a thing on its own
p.emitter = hairstart #the object used for emitting
p.guides.append(hairshape1) #adds a curve to the list of guides
p.guides.append(hairshape2)
p.guides.append(hairshape3)

dunno if such a change would be feasible nor if it makes really sense, but 
thought to mention as the issue came up. anyhow back to reality:

> - In the future I'd like to both extend Particles to support other
> Object types, as allowing multiple layers of particle systems on top of
> each other. That would mean something like
> Object.Particles[0].VelocityNormal(value) or make it like:

ok.. this is a bit of a challence for the API design: should we already 
prepare for that, and make object.particles a list which now only has a zero 
or one member, but later can have more? that way scripts that now start using 
it would not break 'cause they'd always have to do object.particles[0] to get 
the system. 

another option would be now to have just object.particle that potentially 
refers to the only possible particle system, and add object.particles when 
the new system is introduced, and keep object.particle then too pointing to 
particles[0] for backwards compatibility (and as a convenient way to access 
the first, i guess often only, system too).

> -Ton-

~Toni

>
> On 16 Nov, 2005, at 6:47, Janne Karhu wrote:
> >> * is there any reason why the textures (and materials) don't clamp
> >> the same?
> >
> > Some mixups from me and some from different coding times so no,
> > atleast I don't see
> > any reason for this (Ton you'll fix?)..
> >
> >> * is there any way to "disable" speedtex?  There's this check in
> >> effect.c:
> >>     if(paf->speedtex)
> >>        mtexmove= ma->mtex[paf->speedtex-1];
> >>   but I can't see where speedtex can be set to 0
> >
> > It can't be actually set to zero anywhere, but if I remember correctly
> > the "if" was a
> > safety for old blender files which didn't have the speedtex variable
> > so it was set to zero,
> > but I covered that with sdna conversion later (iirc again, otherwise I
> > really should have).
> >
> > Hope this helps.
> >
> > Janne
> >
> > ----- Original Message ----- From: "Ken Hughes" <khughes at pacific.edu>
> > To: "bf-blender developers" <bf-committers at projects.blender.org>
> > Sent: Wednesday, November 16, 2005 2:38 AM
> > Subject: [Bf-committers] Particle questions
> >
> >> I'm trying to add BPy support for the new particle system features
> >> and have two questions:
> >>
> >> * is there any reason why the textures (and materials) don't clamp
> >> the same?
> >>   -- timetex: between 1 and 8 (should be 10)
> >>   -- speedtex: between 1 and 10
> >>   -- mat[] between 1 and 8 (should be 16)
> >>   -- omat: between 1 and 16
> >> * is there any way to "disable" speedtex?  There's this check in
> >> effect.c:
> >>     if(paf->speedtex)
> >>        mtexmove= ma->mtex[paf->speedtex-1];
> >>   but I can't see where speedtex can be set to 0
> >>
> >> And a related question for BPy developers:  is there some existing
> >> code which gets/sets a three-way toggle (TOG3)?  My first thought was
> >> to borrow from the material (MTex) API but can't see it doing
> >> anything special.  I need it now for the "TexEmit" setting
> >> (flag2/flag2neg).
> >>
> >> Ken
> >> _______________________________________________
> >> Bf-committers mailing list
> >> Bf-committers at projects.blender.org
> >> http://projects.blender.org/mailman/listinfo/bf-committers
> >
> > _______________________________________________
> > 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
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers