Hi all,
please help me with this noob problems:
if you look at image, square spacewarp in scene is deflector001. after its collision, particles are affected by wind but everyone change its instanced shape (cherry becomes strawberry etc)…how to maintain ever the same instanced shape?
another question about a random rotation around “looking camera axis” for a better instace camoufage, how to?
Maintaining the shape through events should be fixed by enabling “Acquire Current Shape” in the shape instance operator and moving out of the global to event 01.Shape Instance doesn’t necessarily work like the other operators when placed in the global event, not sure why.
Did you switch to Allow Spinning in the Shape Face operator? That may do the trick.
EDIT: Looking at the flow you posted I think though you may run into problems with multiple events and using the shape instance group. A possible solution, since you have such a low number of different shapes, would be to create a new event stream for each shape.
hi johnny,
I moved the “shape inst” operator to event01 and enabled “Acquire Current Shape”:
a stange scale reduction appears then I moved also the “shape facing” op to event01 and all seemed right…obviously other events need a “shape facing” op but introducing them now my shape is ever a raspberry (with a wrong scale). problem not solved.
in regard to the second question:
I want a random rotatio for the instanced shapes to avoid the same pose and then, if possible, a spin value when they are swept away (in respect of a constan camera facing orientation).
to avoid multiple event I can create for every fruit shape various copies with different rotation and solve…I just wanted to know if the “rotation” op could make life easier 
.
another question:
a pwrapper version who works in net render? in my 2 demos (1.010 and 1.013) its mesh disappear in render, the mesher comp obj not work properly and cache feature not solve the entire scene (600 frames). 3d alien forum reports some of this bugs but no solution and large time to response.
The Scale issue is more than likely because you are not using “Local Space” in your shape facing op. Try that. I mentioned previously that you may have issue using multiple shape facing operators with a shape instance + group, although I may have not been very clear.
I think a better approach since you are using cards would be just to have a single shape instance object, create a multi sub-object material, assign all of the different fruits to each sub material, add a material static op and instance the MSO material. There is no real reason to use individual shapes in this case.
EDIT: Attached a scene file.
You could certainly build a box#3 op that would do all of the above in a single operator
a better approach, surely but my fruits planes have different sizes because some contain stems.
of course your material approach is good…I’ll try it also.
orbaz want a professional address to send an evalution copy…I don’t like this policy for this type of evalutions (my opinion).
many thanks johnny for your help.
about the pwrapper mesher…anyone has news about a stable verson for net render?[left][left]
[/left]
[/left]
The vanilla particle flow material support, IMO, is stronger than shape support, materials are much easier to carry/assign downstream than shapes in vanilla pflow. Box#2 some improvements were made at the local container level that make it even better/easier to define. Of course Box#3 hands down for the most control/speed in pflow currently possible for both materials and shapes (and everything else for that matter ).
About the evaluation thing, I can’t speak for Oleg, I believe he just wants to know exactly who he is sending evaluations out to, I imagine to minimize the chance of piracy, since AFAIK they are full-version time restricted demos. You get 30-days no holds barred evaluation.
About the Scale, you could birth script this and when assigning the material you could also define the scale of the particle, as another option. It we be a little bit slower due to the script evaluation but it shouldn’t kill it speed wise, you can regain most of it with the addition of a cache operator (with the exception of the first run as the cache builds).
Sorry no help with the pWrapper issue, their forum is pretty dead too, ie the developer doesn’t seem to visit that often, maybe try e-mailing them.
in other words, I need to semplify a simplified method to simplify the life
I’m sure that box#3 is the “key” to work properly with particle flow because box#1 is slow slow slow without any sort of trick…2 years ago (or 3?) oleg has sold its box#1 package but its speed is still at max 6 version…or not?
an example script somewhere?
I know, glu3d is the first plugin who step backproportionally at its development speed
Thank you for your time johnny…
lol, I think we all do :)
Well for some odd reason assigning a Shape in a Birth script isn’t working for me. Although using a standard script operator does. Just place this Below any material operator. It needs to be below it so it can alter an already assigned Mtl ID.
This script set the position to vertices of specified object, sets the shape, re-assigns a new random material ID (1 through 6 the amount of subobject mtls), then adjusts the scale according to the material ID.
on ChannelsUsed pCont do
(
pCont.useTime = true
pCont.useShape = true
pCont.useScale = true
pCont.useMtlIndex = true
pCont.usePosition = true
)
on Init pCont do
(
global theBirthMesh = snapShotAsMesh $plane01 -- Your Birth Object
global theShapeMesh = snapShotAsMesh $plane02 -- Your Particle Shape
)
on Proceed pCont do
(
count = pCont.numParticles()
t = pCont.getTimeStart()
if t < 0 do
(
for i in 1 to count do
(
rndInt = 1 + pCont.rand0X 6 --6 is the amount of sub-object materials, then generate a random Integer for Mtl ID add 1 so 0 isn't used
int = rndInt
pCont.particleIndex = i
pCont.particlePosition = meshOp.getVert theBirthMesh i --Place particles on specified object
pCont.particleShape = theShapeMesh -- Define Particle Shape
pCont.setParticleMtlIndex i int -- Set the Material Index NOTE:you material operator must come before the Script op.
/*
Set your material IDs according to the random integer that was generated earlier
Oddly enough translation seems to get lost some along the lines mtlIDs 1,2 return mtl 1, not sure
if it is an issue with Multi Sub-object or the way pflow handles material indexing
Below are 3 different ways to apply scale
*/
if int <= 2 then
(
pCont.particleScale = 1.5
)
if int == 6 then
(
pCont.setParticleScale i 2.5
)
if int == 7 then
(
pCont.setParticleScaleXYZ i [2, 1, 1]
)
)
)
delete theBirthMesh --Remove the copy of the birth mesh
)
on Release pCont do
(
)
Attached quick example Max2010:
birth script doesn’t accept a shape, instance obj doesn’t accept a group of shapes…
now I understand because max particle users, all, lose their hair when works in production
thanks for script (really), I’ll study it to maintain my hairs on his head 
if you are interested to view the first sketch of my “exercise” (not even with the changes you’ve suggested me), this is a link:
in this forum, reading various posts, my idea is that you are one of most advanced pflow (and friendly help) user and hristo velev is the same for thinking particles…who has more hair (the usual comparison between TP and PFlow)??
Hey that looks pretty good, it makes me want to drink fruit juice
I saw a few particles cross each other, not sure, maybe, just maybe, a Keep Apart op might keep that from happening, hard to say though because of the shape facing operator is forcing rotation and alignment with the camera.
Thanks for the kinds words, I am only trying to follow in Bobo’s footsteps, he is the mentor, I am his humble (well mostly humble) apprentice
LOL, Hristo definitely has more hair! …and this is just a guess, I think maya particle users could be bald 
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.
