What's that guy, Lukas, doing? ParticleSystem Rewrite, C# and TS IDE's

  • 1
  • 2
14 posts Page 2 of 2
JeffR
Steering Committee
Steering Committee
Posts: 847
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Mon Jul 13, 2015 5:37 pm
Az had passed along that you were trying to puzzle out some parts of the componentization of the particles.

Any area in particular? As a fellow componenteer, I may have some ideas/insight that could be useful :P
Azaezel
Posts: 410
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Mon Jul 13, 2015 6:38 pm
For those playing the home game, this cropped up due to hitting the review-phase for https://github.com/GarageGames/Torque3D ... f256d85R83

While that will function for singleplayer, and unique datablocks per-instance,

A) sending it as a raw string falls apart when a client connects to another client that is a host due to the fact that server and objectIDs are not identical across the network, so needs something along the lines of https://github.com/lukaspj/IPS-Lite-for ... 2914-L2916

B) It demonstrated a case of needing an area to define object-instance unique value storage in an extendable manner.

The suggestion therefore was to retool the particlesystem class into a systemBase + subclass collection similar to GameBase, possibly with a standardized packupdate and a packupdateEX for the subclass to denote shared vs subclass-specific data-transmission.
chriscalef
Posts: 375
Joined: Mon Feb 09, 2015 7:48 pm
by chriscalef » Tue Jul 14, 2015 6:00 am
Just dropping in to say this entire conversation is +1 awesome. Thanks for all the hard work!
LukasPJ
Site Admin
Posts: 388
Joined: Tue Feb 03, 2015 7:25 pm
 
by LukasPJ » Tue Jul 14, 2015 10:43 pm
So, removed the linked list and threw in an array where particles are always next to each other.
You can find the results here.
The high amount of performance going into vector resizing is to be expected, because there's a low framerate with 1000 particles, meaning the system will try to compensate for the low framerate be emitting more particles in the frames there is, meaning there will be frames where there are more particles than what the "expected" amount was (since they will only be removed next frame) -> resizing to match the amount of particles.

So how does the loops look now? Well for example this has been changed to:
for (U32 idx = 0; idx < mParentSystem->getParticlePool()->getCount(); idx++, buffPtr -= 4)
   setupBillboard(mParentSystem->getParticlePool()->GetParticleAddress()[idx], basePoints, camView, ambientColor, buffPtr);
I'm not sure why that didn't give any particular improvements, might just be because of the fact that it's all percentages. It's still a plus though, as it uses a bit less memory, so if we stay at the same or better performance it's fine.

So step 2, optimize those bottleneck functions, there are a lot of stuff to be done there. We've already discussed it a bit on IRC.. I'll be back with news when I've worked something out :P
  • 1
  • 2
14 posts Page 2 of 2

Who is online

Users browsing this forum: No registered users and 2 guests