@t0neg0d said:
This completely depends on what you are doing with them. In the case on a static emitter shape an no forces being applied to the static particles, they are generated once and no update is run against the mesh.
If the mesh is animated, the particles are animated, influencers are present and enabled… anything that would alter the particle placement, it is generated every frame.
Just one my request. To have a boolean - Emitter.generateOnce(true). Even if mesh has animation. It can be static sometimes.
Or Emitter.doUpdate(false).
Something like this to have power of update the emitter.
@t0neg0d said:
@normen , you're a tool... go do something useful for a change.
Yeah, I am german but if people talk like this to me my respect for them drops to zero, causing me to not care about my choice of words or choice of argumentation anymore. Remember you were asking me to speak up, I made clear that we had this exchange already and theres no use in telling you anything once again.
Just for the record…I pointed Zarch to the repo you gave me by PM, I had no idea it was secret work as it was a google code public repo.
I apologized for this before I find out that you had posted the link to the repo in your first thread about your particle system…Then i find myself less guilty and just went “whatever…”.
Now since that conversation is going nowhere, I’d rather be kept out of it. So please, if you mention me don’t put the @ before my name.
That’s a shame, because what you did looks pretty cool. I’m not fond of the “not in sdk editor” and the “can’t save to j3o” but that could be worked out. But I don’t know how all this is gonna end up…
@normen said:
Yeah, I am german but if people talk like this to my my respect for them drops to zero, causing me to not care about my choice of words or choice of argumentation anymore.
Well… me too =) Minus the German part, of course. Here is the deal… this matters very little to me past a full nights entertainment. I don’t really think your an ass… I don’t. It does bother me that neither of you see a stitch of an issue with this, but… in the end… it really doesn’t matter one way or the other.
I do thank you and @pspeed for the fun tonight though… I was pretty sick of staring at code.
@t0neg0d said:
Well.. me too =) Minus the German part, of course. Here is the deal... this matters very little to me past a full nights entertainment. I don't really think your an ass... I don't. It does bother me that neither of you see a stitch of an issue with this, but... in the end... it really doesn't matter one way or the other.
I do thank you and @pspeed for the fun tonight though… I was pretty sick of staring at code.
I would be happy to see the issue if evidence had ever been posted. I looked at both code bases back when they were both still available and saw no direct infringement beyond what was already stated. It’s really hard to find things from that side, though. It would have been really easy to point at actual issues from the perspective of the person who saw the actual issues.
We should probably have a process in place for how to deal with these sort of community member to member disputes… but I suspect step 1 or 2 would be to provide evidence of infringement. I don’t see how it could be otherwise.
@nehon said:
Just for the record...I pointed Zarch to the repo you gave me by PM, I had no idea it was secret work as it was a google code public repo.
I apologized for this before I find out that you had posted the link to the repo in your first thread about your particle system...Then i find myself less guilty and just went "whatever....".
Now since that conversation is going nowhere, I’d rather be kept out of it. So please, if you mention me don’t put the @ before my name.
That’s a shame, because what you did looks pretty cool. I’m not fond of the “not in sdk editor” and the “can’t save to j3o” but that could be worked out. But I don’t know how all this is gonna end up…
I’m actually really not upset by the thread here… it’s all in good… well… fun I guess. And the j3o support is possible, however… the SDK plugin is probably beyond my expertise (if I have an expertise).
I couldn’t even begin to pretend that I’m capable of doing this. Though, I would suggest someone goes through the editor I put together and let me know if it is even possible the the SDK… it’s pretty extensive.
@pspeed said:
I would be happy to see the issue if evidence had ever been posted. I looked at both code bases back when they were both still available and saw no direct infringement beyond what was already stated. It's really hard to find things from that side, though. It would have been really easy to point at actual issues from the perspective of the person who saw the actual issues.
We should probably have a process in place for how to deal with these sort of community member to member disputes… but I suspect step 1 or 2 would be to provide evidence of infringement. I don’t see how it could be otherwise.
I made the code public, like you said… it still was handled in an inappropriate manner.
@mifth said:
Just one my request. To have a boolean - Emitter.generateOnce(true). Even if mesh has animation. It can be static sometimes.
Or Emitter.doUpdate(false).
Something like this to have power of update the emitter.
Thanks.
I’ll make it happen. Just to clarify, this is to disable the update loop solely, correct? I did something similar with the stock influencers. initialize and reset are still called whether or not the influencer is enabled. enabled/disabled simply excludes the update loop.
And fuck it… I’ll just include the code… no need to pms over this. I’d rather have multiple people working out any quirks I may have missed then trying to manage it myself.
Do not make a joke about PMS, do not make a joke about PMS…
On serious note, I think that everything will benefit in longer run from having the source code. I really doubt that anybody is going to pull any shady moves with the source, given previous experiences.
@t0neg0d said:
I'll make it happen. Just to clarify, this is to disable the update loop solely, correct? I did something similar with the stock influencers. initialize and reset are still called whether or not the influencer is enabled. enabled/disabled simply excludes the update loop.
Yep, the idea is to generate static particles once and not to update them anymore.
For example i want to create 30 trees with particle leaves. I need no update for them - for better performance. They will be like a static meshes.
@abies said:
Do not make a joke about PMS, do not make a joke about PMS...
On serious note, I think that everything will benefit in longer run from having the source code. I really doubt that anybody is going to pull any shady moves with the source, given previous experiences.
Lol… see… my bitching amounted to something after all.
@mifth said:
Yep, the idea is to generate static particles once and not to update them anymore.
For example i want to create 30 trees with particle leaves. I need no update for them - for better performance. They will be like a static meshes.
This was actually the original consideration behind static particles… it just worked out that it does a lot more than this. I have a test here of using the emitter to place grass, trees, rocks, plants on terrain generated from a noise function. It works really well.
EDIT: though there are better way of doing this (like vertex displacement in a shader), you can use influencers to say… make the leaves blow in the window, etc.
EDIT 2: more on the subject of vegetation: It would be nice to have an influencer that allows you to set up params to define where these objects should not be placed based on the height map generated per tile, etc
EDIT 3: Nice thing is… you could use one emitter to place all trees for the tile as a single mesh… pass this mesh to the next emitter that generates the leaves as a single mesh. The possibilities there are pretty much limitless.
@t0neg0d said:
This was actually the original consideration behind static particles... it just worked out that it does a lot more than this. I have a test here of using the emitter to place grass, trees, rocks, plants on terrain generated from a noise function. It works really well.
EDIT: though there are better way of doing this (like vertex displacement in a shader), you can use influencers to say… make the leaves blow in the window, etc.
EDIT 2: more on the subject of vegetation: It would be nice to have an influencer that allows you to set up params to define where these objects should not be placed based on the height map generated per tile, etc
EDIT 3: Nice thing is… you could use one emitter to place all trees for the tile as a single mesh… pass this mesh to the next emitter that generates the leaves as a single mesh. The possibilities there are pretty much limitless.
That’s really great! I think your Designer will be super useful!
But… please, stop with the resentment-jabs. It serves no purpose. I have gone public on the subject, I mostly agree on your stance, but it’s time to move on and drop it completely.