PDA

View Full Version : PFX: scene autopsy-- what's going on here (attached)



jeric_synergy
04-13-2016, 07:34 PM
Just trying to follow a tutorial on YouTube: (see attached) why is it that the collision with the Collision Object doesn't cause the emitter to cough out particles until it's almost reached the end of the object? That is, why doesn't emitting being as soon as contact begins?

Thanks.

133420

++++
MORE: managed to get it to do zero just by playing around (scaling emitter object). Oh, what fun. :devil:
++++
MORE2: So, if I bring the collision object in from the minus X side, it works as expected, but if I bring it in from the plus X side, it does not.

-- Of course. :eyeroll:

prometheus
04-13-2016, 07:58 PM
Just trying to follow a tutorial on YouTube: (see attached) why is it that the collision with the Collision Object doesn't cause the emitter to cough out particles until it's almost reached the end of the object? That is, why doesn't emitting being as soon as contact begins?

Thanks.

133420

++++
MORE: managed to get it to do zero just by playing around (scaling emitter object). Oh, what fun. :devil:

if you use nozzle surface it would work..but thatīs not what you want, but the thing is it has trouble reading the vertices location it seems, so go to the object properties of the tropical emitter/fx and then particle tab, uncheck fixed random and now it should work with vertices.

And to counterpart the calling of evil spirits:yoda:

jeric_synergy
04-13-2016, 08:31 PM
if you use nozzle surface it would work..but thatīs not what you want, but the thing is it has trouble reading the vertices location it seems, so go to the object properties of the tropical emitter/fx and then particle tab, uncheck fixed random and now it should work with vertices.
Well, that's just begging the question, isn't it: WHY would it have issues with detecting the vertices on this dead-simple object?

Also: why does it work when the collision object approaches from minus X and not plus X??

Seriously, working with this made me dl Blender. :P
(I'm not kidding.)

jeric_synergy
04-14-2016, 12:13 AM
I also have seen issues with the BIRTHRATE parameter repeatedly being set to zero. This happens regularly, though at unpredictable intervals.

prometheus
04-14-2016, 07:30 AM
Well, that's just begging the question, isn't it: WHY would it have issues with detecting the vertices on this dead-simple object?

Also: why does it work when the collision object approaches from minus X and not plus X??

Seriously, working with this made me dl Blender. :P
(I'm not kidding.)

Not sure exactly, but I suspect the fixed random option overides some default parameter on how the particles are positioned to get a different distribution that is not so random, and by doing so it seems it brute force change the original position...thus the particles are not recognized properly by this collision even, problem solved anyway right?

Yeah..blender, you will go grr.because of other stuff in there, it has different ways of working with particles...cool to be able to use paint weight maps though and use that as birth emitter..but other things will be more awkward and harder than to use lightwave relativly easy to set up particles.

You got to get used to the blender UI ...so good luck with that.

Michael

jeric_synergy
04-14-2016, 08:09 AM
Not sure exactly, but I suspect the fixed random option overides some default parameter on how the particles are positioned to get a different distribution that is not so random, and by doing so it seems it brute force change the original position...thus the particles are not recognized properly by this collision even, problem solved anyway right?
I have no idea what you are saying here.

prometheus
04-14-2016, 10:45 AM
I have no idea what you are saying here.

no need to..the problem is fixed anyway, just make sure to uncheck fixed random, for what it does..hard to describe...this is what is documented in the 2015 help files..

"Particle resistance adds an air resistance effect. Particles will move slower as you increase this value.
Life time (frame) sets the life of the particles in frames. Once a particle is born, it lasts only this long.
If you activate Fixed Random, random calculations are constant, so they yield more predictable
results."

Maybe that will not make you wiser, only more confused:D

jeric_synergy
04-14-2016, 11:09 AM
Prom, I often find your "stream of consciousness" style of posting difficult to understand-- you may want to give more context to your writing, since sometimes to me it seems extremely disjointed. FWIW & YMMV.

For instance, I'm not sure why you think this problem is resolved.

prometheus
04-14-2016, 12:03 PM
Prom, I often find your "stream of consciousness" style of posting difficult to understand-- you may want to give more context to your writing, since sometimes to me it seems extremely disjointed. FWIW & YMMV.

For instance, I'm not sure why you think this problem is resolved.

Yes..sorry to say..I have noticed that is the case quite often with you and me, not sure if itīs my way of thinking ..or if it is how it translates in bad english translation from me..without consistency, good to know how you perceive it...and I will keep it in mind.

Or Maybe our way of reasoning is on quite a different bandwith so to speak..if you understand:D some folks understand eachother better or less better..even if they are from the same country etc.

You say for instance this..and point to why I would think the problem is solved? I would say that has nothing to do with my thinking..I would say you should tell me if it worked or not? at my end it works..problem solved, if you on the other hand did not get it solved by unchecking fixed random?...then I haved no clue unless you verify it back, so..did it work or not?

The question on why it is working or not working ?..that is a different matter..maybe not for you, sure..one may want to know Exactly why it works like it do..fully understandable..and I see that is something you seem to want...But sometimes I surrender to the fact that tools are not properly described or completly lacking and I can not get the full understanding of it..and I am in fact just guessing.... and that is why you feel my thoughts disjointed?

So now I am confused wether or not I did help you in this matter?
If you had serious issues understanding this..then I think our communication is in severe trouble.

JoePoe
04-15-2016, 10:07 AM
Just trying to follow a tutorial on YouTube:

What tutorial? Link? Are you getting a different result then they do?

It appears that particle generation is taking point order into consideration when birth rate is set to vertices.
Once vertex #1 is contacted, all others become "alive" in order. If you're coming at the object from the direction opposite to point order, nothing happens until point #1 is hit. Because the collision object at that moment is already in contact with #s 2,3,4,5,6, etc, those fire simultaneously along with #1.

Why? Dunno? never noticed that before. I could be way off..... just my impression.

Edit: Here's another example. Collision ball hitting the corner of a flat plane. Corner point is vertex #1.

133444 133445

Points 1-6 are hit (for all intents and purposes) at the same time. #7 slightly later.
None of the other points (which clearly have been contacted by the collision object) have fired... even though they were hit first by the leading curve of the sphere. The next point to fire is #8 which was missed.

jeric_synergy
04-15-2016, 10:57 AM
It's on my other machine: recently on FB, results in a kind of "tropical flower" look. Quite nice, although the audio/text free tutorial is a chore to view.

I'm thinking you're onto something, JP: that certainly looks right. I've submitted the scene to LWG bug fixers. I'll add your speculation. The tute uses SURFACE, so the poster would not have run into this. Still, needs to be quashed.

There's some really intriguing stuff on YT if you search "lightwave particles".

I have the impression that emission direction is somehow affected by the trigger object: is that likely? While it is technically a "collision" object, I'm using it mainly as a trigger: is collliding per se a default?

prometheus
04-15-2016, 11:29 AM
I donīt see why a collision Event would affect the direction, it has nothing to do with it, just birthrate...if it in your scene does have that effect..then you might have something else going on, otherwise truly a bug..but based on what I can see on the provided scenefile, that shouldnīt be the case.

You do however have explosion force in there..that is probably what is directing the particles, turn that of and you should have nothing of directional particle motion to speak of.
And you also got a setting of -4.7 in x velocity for the particles...which of course pushes the particles.
Unless you talk about other scene attempts?

Turning off explosion and velocity motion, and you will see how the particles is distributed on the cylinder at the end, check and uncheck fixed random and you see the difference..finally turn on fixed random again...and change birth rate to different values..and you see some differences...I wonīt go in to much more in to detail on that, since I am not completly sure whatīs going on...regarding birthrate, fixed random and how it calculates particles according to the help files ..

"Particle resistance adds an air resistance effect. Particles will move slower as you increase this value.
Life time (frame) sets the life of the particles in frames. Once a particle is born, it lasts only this long.
If you activate Fixed Random, random calculations are constant, so they yield more predictable
results."

Hope the bug crushers can help you out better than I.. my expertis is limited here, I only gave you sojme feedback on my findings here.

prometheus
04-15-2016, 12:04 PM
Of course...rotate the cylinder 180 degrees in the heading direction... and you wonīt even have to mess with fixed random, it should start emitt when the collision event object arrives..since we mentioned particles following point order, those points that made up the cylinder in your case was at the end, so rotating the cylinder perhaps is one solution? simple as that?..ehh:) point order was of course also mentioned already by joepoe.

jeric_synergy
04-15-2016, 12:31 PM
A lot of this isn't about a specific object, it's about generalized workflow. This is a test object, why would it behave so oddly? An actual object would have specific orientation that couldn't blithely be flipped about.

I don't want to have to continually second guess my tools: they should work as expected.

prometheus
04-15-2016, 12:37 PM
A lot of this isn't about a specific object, it's about generalized workflow. This is a test object, why would it behave so oddly? An actual object would have specific orientation that couldn't blithely be flipped about.

I don't want to have to continually second guess my tools: they should work as expected.

I Understand that, though I donīt think itīs a matter of a bug in terms that something got wrong in the latest versions..maybe call it lack of proper feature, this is how particles works..following point order I guess, so maybe by entering nodes and change point order, or use some model plugin to re-arrange point order, until the lw team develops it so it doesn matter..if possible that is.

I understand why you mentionen general workflow...Now, but you didnīt for your very first post it was a matter of this case and not a general workflow with other situations..at least that didnīt came through in the first posts.
It isnīt like you said,...this have to work not only on this object, but on other objects that canīt be blithely flipped about.

Initially It was a question on what is going on Here...not a question described as..(by the way thereīs all other possible object or scene variations this must work on), you at least got answers to why it works on one minus x side...which isnīt specificly related to minus x or plus x sides, rather how the cylinder was created with itīs point order.

prometheus
04-15-2016, 12:50 PM
I must add, since the fixed random forces the particles to generate by point order(at least I believe that is the case) unchecking it overrides that and makes it possible for them to start itīs birth on all vertices at the same time,
Edited..(just seemingly starting at the same time..itīs still randomly) .thatīs the only explanation I can think of.

(Geez...sorry if my spelling is loosing characters, my keyboard is giving up on me..especially the t letters.)

Edited again..after unchecking, fixed random on a spline for instance..will if using birthrate set to generate by sec...that will cause particles to birth randomly on the spline starting by picking one vertice randomly, but checkin fixed random ..the particles will follow point by point in order from which they were created.

using a collision event starting from the origin where the points where created, and fixed random..the birth order will be the same as generate by sec and fixed random, turning fixed random off, and it will still be the same, generating by point order..which is different from birthrate per seconds even thoughfixed random is on...so it seems it doesnīt do any random birth when it is set to collision event and fixed random is unchecked.
I hope you could swallow that description :)

jeric_synergy
04-15-2016, 02:10 PM
It isnīt like you said,...this have to work not only on this object, but on other objects that canīt be blithely flipped about.
IMO, that's a GIVEN. Nowhere would one expect that a triggering event is predicated on point order, that's ridiculous, that's what the triggering object is for.

prometheus
04-15-2016, 02:53 PM
IMO, that's a GIVEN. Nowhere would one expect that a triggering event is predicated on point order, that's ridiculous, that's what the triggering object is for.

My thoughts on it, itīs not a perfect world, things arenīt black and white, things can be more complex than what first meets the eye..if you do not want to bother about point order, use surface mode, then you will not have that problem,
only other issues :D (perhaps depending on what you want) since particles will not spawn regulary from the vertice grid based so to speak, only from a bit random distribution from the surface, I reckon there might be a special reason for vertice spawning instead of surface?

So one advice would be to change it to surface mode, that would make it behave as you expected with a triggering object, with vertices it gets a bit more complex, but itīs not overly complicated to fix, so if that wonīt do, change the fixed random, if that wonīt do, change the object so you got the point order right, if that wont do..send a bug report on something that most likely isnīt a bug, then redo it to a feature request.

Now that is a lot of energy spending on figuring out and complaining about it not working as expected, for me..I do not see this as an issue, I wouldnīt think of it as..(One would expect it too behave), well initially perhaps, but not if you think about it a bit more ..so regarding to the ways you can fix it as described, itīs fine with me... but I am not you and you not me, so itīs up to you
to spend the time with it:D ..then we are unfortunatly mostly on a different bandwidth/frequency quite often;)

good luck though..

prometheus
04-15-2016, 03:13 PM
Comment removed...

jeric_synergy
04-15-2016, 04:19 PM
JoePoe:

here's the tutorial:
https://www.youtube.com/watch?v=YNc11oRQ_us

here's the result:
https://www.youtube.com/watch?v=66Nh1CyiUzM

JoePoe
04-15-2016, 04:26 PM
Wow, that is pretty cool!

FWIW I was a bit surprised at the vertices thing. If a limited region of a surface can spawn particles upon collision than why not a limited region of vertices. Even out of order.

Here's the workaround I'd probably use:
Copy the (desired) points of your object to a new layer > make all one pt Polys (single click).
In layout make that layer your emitter and use the Object Surface as your nozzle. Collide away :)!
Dissolve 1 pt poly layer, so just particles render. (edit: but to be fair, the 1 pointers will be inside your voxels so might not matter. On solid voxels that it :hey:)

jeric_synergy
04-15-2016, 05:00 PM
FWIW I was a bit surprised at the vertices thing. If a limited region of a surface can spawn particles upon collision than why not a limited region of vertices. Even out of order.
Of course: the alternative is ridiculous.

On the plus side, I got to report (yet another/a) PFX bug. On a subsystem that's probably entirely renovated.

Dastardly clever work around. I know the poster actually DID use Surface, but if one were determined to use Vertices, that's clever.

jwiede
04-17-2016, 05:21 PM
On the plus side, I got to report (yet another/a) PFX bug. On a subsystem that's probably entirely renovated.

LW3DG stated volumetrics were renovated, but did you read/view anything from LW3DG suggesting that PFX had been renovated as well? If so, where?

I don't recall any clear indication of improvement on the PFX side of particles.

jeric_synergy
04-17-2016, 05:35 PM
LW3DG stated volumetrics were renovated, but did you read/view anything from LW3DG suggesting that PFX had been renovated as well? If so, where?
I don't recall any clear indication of improvement on the PFX side of particles.
No: I stuck in "probably" as it is purely an assumption, based on A) how buggy PFX seems (YMMV), and B) the time they are taking to get everything done.

So, no, just a guess. I'm not sure which would be worse: a whole NEW set of bugs, or the continued existence of the known bugs.

FWIW, I reported the point order/event trigger bug. :hattip: to JoePoe for characterizing what's going on there.

jwiede
04-17-2016, 07:18 PM
No: I stuck in "probably" as it is purely an assumption, based on A) how buggy PFX seems (YMMV), and B) the time they are taking to get everything done.

So, no, just a guess. I'm not sure which would be worse: a whole NEW set of bugs, or the continued existence of the known bugs.

No worries, just wondered if I had missed something from LW3DG stating they'd also worked on PFX. Personally, I suspect they'll leave PFX alone and work solely on volumetrics, but who knows, time will tell.


FWIW, I reported the point order/event trigger bug. :hattip: to JoePoe for characterizing what's going on there.

Thanks to both of ya for that. The current behavior seems neither particularly "predictable" from docs, nor frankly, all that useful presuming what the user really wants is a pseudo-random emission distribution from vertices.

As for "fixed random", I always interpreted that as indicating "deterministic pseudo-random" for cases where exact replication might be needed, but if that's what it is "supposed" to mean, neither the docs's described function, nor the actual behavior seem to be about that (anymore?). I'm having difficulty coming up with usage cases where "fixed random" behavior (or rather, its absence) would be desirable.

Honestly, I've almost entirely given up on PFX these days, and much prefer C4D + X-Particles. Much more performant, much more flexible/controllable, and available preset configs make it faster to set up for common tasks. Even modo's particles offer ability to store preset configs in a way that speeds setup for common tasks much more so than LW PFX these days, though I still find X-Particles significantly more powerful/flexible than modo's particle engine. I'll agree that building setups from scratch, modo and X-Particles take longer than PFX in many cases*, but realistically the ability to store oft-used setups as presets entirely offsets any greater cost of initial config, IMO.

*: X-Particles and modo particles both offer significantly more functionality than PFX, as well. Combined with ability to store presets of those more powerful configs, I find they offer massive efficiency wins compared to PFX. YMMV, and so forth. At the time of introduction, PFX was amazing, but these days it compares rather poorly to offerings in other packages.

jeric_synergy
04-17-2016, 07:33 PM
Just a guess, but "fixed random" might be for renderfarm applications.

jwiede
04-18-2016, 02:30 AM
Just a guess, but "fixed random" might be for renderfarm applications.

That's what I meant by "deterministic pseudo-random" for cases where exact replication might be needed: Essentially, given the same key always produces the exact same sequence of results. Render farms use such functionality, and there are other use cases where you need to ensure the produced results are visually (and behaviorally) identical each time (f.e. think going back and re-rendering part of a lengthy sequence).

In any case, please let us know if you hear back from LW3DG regarding this bug filing?

jeric_synergy
04-18-2016, 08:53 AM
Usually I hear a bit more than I have already, but it was the weekend. Anyway, they got a sample, so they should be able to replicate it.

jeric_synergy
04-28-2016, 04:41 PM
Issue LB-1768 has been marked as CLOSED.
Link: https://www.lightwave3d.com/account/report/LB-1768/
Fixed vertex emission only being triggered in vertex index order.

Thanks to JoePoe for characterizing what was going on in this bug. :thumbsup: