why the ♥♥♥♥ would we use AEmitters?
would someone kindly tell me how to compare the X and Y positions of objects separately? Tim's one currently does nothing for a bit, then destroys half the map when the game realises the particles are at the same point. im going to try imposing a limit but i'd like to do it another way too.

anything else is laggy because it has more variable than is needed. That's the only way I can justify why 100 MOSRotatings are more laggier than 100 MOSParticles. (the first thing I did when I dl'd this was to change if from particle to rotating)

100 MOSRotatings have as many collision spots to check as there are pixels in the sprite.

MOSParticles only have one. They're simpler to draw and work with.

Does this depend on the resolution of the AtomGroup?

From tests I've run, no, they have the very same amount. The resolution can't go lower than 1 and 1 still means it has more tests to run.

yeah, but it can go higher so there are less atoms -> less collisions.
ugh, everything i do lags like a ♥♥♥♥♥.

I would simply like to point out, the method I described, would treat the entire body as a single object (maybe with attachables for how deformed it is) and would only lag as much as 2-3 MOSRs the size of the entire body of water/other substance (Liquid, solid, or gas). The only problem with this is that it has to be coded from the ground up. Just thought i'd word it one last way, before giving up. I'd honestly like some direct feedback on the idea. (Not 'noone will code that go away' but 'if someone coded it, it would be a(n) X idea and could result in Y')

And as for water as particles, why not make it fewer particles, and then make them out of a material that's as bouncy and flexible as you can, and then make them super light, super fast, but highly affected by gravity, and can't settle. This would mean it is always moving, if you fall in it, it would 'splash' and they'd re-sink, and the object(s) in it, would be pummeled by all the particles, but still not be able to take damage.

the one body thing is alright, but coding self-separating softbodies with no documentation is a rediculous task. you wouldnt use attachables for it though, bloody hell. as for how much lag it would create, you have no idea because it would depend on how it was coded.

it would be a soft body, and pressure changes would be separate soft bodies contained in it. The more deformed it gets, the more 'deform/compress' 'sub-bodyies'.... I didn't mean actual attachables. also, as I said, because this can be used for solids, you could define every map, and MOSR, as different soft bodies. This would make crushing zombies with giant metal boxes way more interesting.

and while coding this with no documentation would be a huge task, but oddly enough, there is some documentation, just not to the standards I suggest.


* This would still use the same materials as CC : Deformation would be by material strength
* Documentation for this does exist, in a grid based system, while I suggest vectors, so its not all 90 degree angles.
*Once coded, would be highly likely to be implemented into the game
*Could be used for water, Volumetric air, and volumetric explosions, as well as a bunch of other physics experiments that I have yet to think of.

The only flaws I really see, are A) the difficulty to make it B) vectored areas inside vectored areas inside vectored areas, C) How do you make it constantly check for new collisions and forces from Not just every edge, but every vector, including internally, including from itself?

other than these 4 pros and 3 cons, can anyone see any that I've missed? I know it seems like a pipe-dream, but there's always coders willing to code some random crap just like this.

the bigger issue is how to get it to check all those collisions and make/remove internal pressure softbodies and decide when to split and whatever without a huge lag spike. what you've just described is possibly more lagging than doing it per-pixel. the documentation doesnt cover much of what you'd need anyway, and WE HAVE NO DRAWING FUNCTIONS.
so basically, we could show it as points at best, unless theres a way to dynamically shift a texture over a constantly redefined polygon?

i have tried coding water as deformable objects before. to make it incompressible, each step, you would get the area of the polygon, and then shift points outward to make it keep the same area. to get surface tension, you can have a small force that moves the two points of each edge together. this force combined with the area preserving force makes surface tension. the area preserving force also takes care of waves. then one last step to make the water infinitely deformable would be to insert points where edges get too long. the steps so far are very fast and simple, but that's the end of the easy part. this works for simple cases, but once you have complex scenarios there's all kinds of things you have to check for, like self collisions, and merging with other bodies, and splitting bodies of water. and those things make it basically just as slow as a well optimized particle based simulation. also, this only simulates from the surface, so you're missing all the vortices and turbulence stuff that happen in the middle.

I Didn't think we had drawing functions, but if say, data added them.... you get the idea.
I also would suggest using the same mat textures we have now, and just control the alpha for pressure.




If you had read my posts, you would see it can handle vortexes. here, allow me to explain how this would work step by step.

Any material can be a soft body, from metal, to soft dirt, to jello, to water, to air, to ligher-than-air gas.


*Start as a single, area (defined by corners, at any angles, to form a closed space)
*Designate how dense by volume the area is. At first it will be uniform
--Start
1*Calculate forces exerted upon 'self' by 'self', generating internal and external deformations from imbalance
2*calculate pressure changes from above forces, generating high and low pressure areas as 'deformations'
3*check for collisions
4* If in a collision, define area to check for changes from collision.
5* Calculate forces from collision, in the area defined in the above step,
6* repeat step 2 for step 5 rather than 1
7* do steps 4-6 for all collisions
8* next frame, do 1-8
--Because high pressure will push on low pressure, Low pressure and high pressure will cycle, as high and low pressure areas, IE vortexes inside the closed body, which can have direct effect on the surface. Density by volume will handle surface tension in different areas, and if it is not in a closed space, the pressure differences will put (heavy on top, zero density on sides) and thus, it will "expand out the bottom" which in English means, IT SPILLS! IT FLOWS!

as a solid, obviously, the object will be dense and stable enough, to support its own weight, unlike water or air, although additional weight, or being beyond its ability can bend, or warp a harder object.

Also volumetric explosions work as telling a soft bodied object that it has 110000 atoms per pixel, and that it is in low pressure, at 0 atoms per pixel, and must expand to equilibrium. the result, Expansion along paths of least resistance until well, equal pressure. In an enclosed environment, this would certainly crush other soft bodies like actors, but if its closed space, has an opening, it would also attempt to pull everything out the opening. See: Rapid decompression.



This method would realistically handle all of these situations, using the exact same method. and as for calculating complex multi-area objects, look at most games in 3d.


Lets use Every FPS as an example

If you shoot someone in the foot it does less damage, than if you shoot them in the knee.
If you shoot them in the chest, it does more than if you shoot them in the knee.
If you shoot them in the head, they just die. usually.


How? Different parts of the 3d objects are different areas.

In Halo 2, there are over 20 different parts of a body, that take different amounts of damage. Sure, they just set the damage to be the same across the board for most of them, but they had to define them independently because the parts of the body move differently.



If they can define both location IN 3D and how much damage taken per weapon,
Then we can define in 2d, Material ID and Pressure, for that many or more areas.


Also, a Well cleaned up and streamlined physics engine with compiled code, will ALWAYS run faster than some crudely made java applet, even if the compiled one uses MORE COMPLEX PHYSICS.









The reason I'm pointing this out, because if after CC is finished, data feels up to a bigger project, he could potentially do, i dunno, CC2. it could use volumetric based physics, in 3d. we'd probably be able to still run it as is, after all it would use 3d video cards. Even if it wasn't 3d, it could potentially load faster if it was compiled properly.


But mostly, because if Data sees this and likes it, he might include it himself. It would have to have very limited use, such as for specifically water, experimental deformable materials, or for explosives.

IE We couldn't replace ALL MOSRs with it, because well... MOSRs lag enough as is, and this would add variables to it! It would be very limited use indeed. I admit, this is an idea for next-gen consoles, not home PCs... Bad idea on my part to post it expecting a positive response here.

by soft body are you thinking of simulating it as just the surface as in like a polygon, or more of a finite element like simulation with triangle meshes? in my previous post i probably misunderstood your idea of soft bodies, as i had been doing a lot of research simulating soft bodies and fluids just by the polygon without any internal springs.

i think i found a huge flaw in tim's code, which i was basing mine on.

DOES NOT WORK BECAUSE THE GAME DOES ALL OF THEM AT THE SAME TIME IN ITS STUPID LOGIC.
so how are we going to do it? its almost like we need to define them with their own tags as they're created and then use that somehow to allow us to identify them on a per-particle but all at the same time basis. ugh. ugh. damnit CC...
solutions?

This topic has devolved into concentrated dumb. This is Lua, not C/C++. You're not coding softbody anything into CC at the moment. The functions necessary are not available and the case is pretty much closed based on that.

You don't have the source code. You just can't say "hufr durfr there's some guy out there somewhere and there sure are a lot of coders here willing to do this.." when there isn't. There's a whole lot of people like Miles, who want to talk about it but not take the time to learn or study it code-wise. People who are already familiar with Lua like myself or Tim know this is just an impossible pipe dream, and can not be done.

Sorry to be critical but there isn't anything substantial about this entire discussion. It's completely shallow and you should really reference what functions you intend to use for these "calculations" of yours.


god why did I even bother posting miles doesn't have a clue what he's talking about at all so dumb this topic isn't even about lua any more it's stupid conversation between one guy who uses an inferior language, one guy who doesn't know what he's talking about, and one guy who tries but doesn't know what he's talking about

oh and geti you're wrong why would that need to be run separately or whatever you're getting at oh actually I think you're trying to say we need a thread for every particle's calculation so they're not run at the same time great idea