SFML community forums
Help => General => Topic started by: ast on October 03, 2015, 10:38:05 pm
-
Hi all,
I did some experimentation with Thor particle systems and was faced with the following. My collision detection schema needs to save state information to each object that can collide. Therefore, in order get the Thor particles collide, I would like to extend the thor::Particle to contain the new attributes for the collision state information, but of course not to change the Thor library files in any way. Is there a feasible way to do this?
Being not a seasoned C++ expert, I come up only deriving ParticleExtended from Particle and include the things I want in the derived class. But as I am instantiating a ParticleSystem and not a Particle this probably would not work this simple. The other option I can think of is to maintain a map from a particle pointer (Particle*) to my collision state data and in my CollisionAffector I could retrive the correct data for each particle using the map. But this seems a bit awkward too. I would be glad to hear if anyone could suggest other alternatives.
Thanks,
ast
-
As outlined in the progress list (http://www.bromeon.ch/libraries/thor/progress.html), user-data for particles is a planned feature for Thor 2.1.
Inheritance won't work, Thor's design is almost never based on it. I have considered different approaches, and the most promising one so far were maps. Particles would get a new attribute (an ID) that can be mapped to various user-defined properties. The challenge is to keep it synchronized with the particle container and to provide an easy interface that can be used inside emitters and affectors.
This is not supported yet, I'll try to have a look at it soon, but I can't promise a date. If you need it right now, you could hack something together by abusing one of the existing thor::Particle attributes if you don't need them.
-
Hi,
Thanks for the answer. I have other aspects to work with so I am in no hurry. It is nice to know that the issue I bumped into was valid and being addressed already. The tip of exploiting some of the existing data of the particle to store the data I wanted may work also. I might even give it a shot. In my experience, both the SFML and Thor has pretty much always worked as I would have expected them to, so thanks for the good libraries :).
Regards,
ast
-
Exploiting the existing particle attribute yielded a working solution. It is easy to hide information in the lowes bits of particle scale so that no one notices. Originally I would have liked to store a little bit more information per particle but this 'lite' solution seem to work quite acceptably as well.