Thursday, July 23, 2009

External point caches


  • External files should be named "identifier_frame_index.bphys" or "identifier_frame.bphys" where:
    • "identifier" is a freely choseable name.
    • "frame" is the cached frame number.
      • Six digits padded with zeros!, for example "000024".
    • "index" can be used to tell caches with the same identifier apart.
      • Two digits starting from zero.
      • The index and the underscore before are optional. If no index is present the index number in ui should be set to -1.

  • Cache file format is pure floating point numbers (in binary, not text!) with each particle's data one after the other with the following data members:
    • 3 floats: particle's location vector
    • 3 floats: particle's velocity vector
    • 4 floats: particle's rotation quaternion
    • 3 floats: particle's angular velocity vector
    • 1 float: frame of the actual data (this can be non-integer for particles that are born or die between two integer frames, but otherwise should be the same as the "frame" in the file name)

  • Cache files don't have to exist for each frame.
    • Frames without actual data are interpolated from surrounding frames that have data.

  • For now, the external cache panel has controls for particle emission start, end, lifetime and random lifetime. These should be set according to the original simulation data. These will go away in the future when cache files can hold the needed additional data.
Posted by at

5 comments:

  1. Kernon DillonJuly 23, 2009 at 5:37 AM

    As always, great developments!

    I have a question, though. Will there be an easy way to know the details of the external cached data (start, end, etc.)?

    I see a lot of potential for an online repository of cached particles but it might be a bit cumbersome without having the details of the data load with the cached particle data. Maybe cached particle data, that is the result of using the new "external" feature, could have a .bphys "header" file that would contain the necessary data. Also, maybe it would be good for the user to have the option of reading the header file during the import. I guess there would be scenarios where you might not need or want that additional info, but it could definitely save time, especially if the cached data is shared between users (e.g. - a repository site).

    Thanks for your time!

    ReplyDelete
  2. jahkaJuly 23, 2009 at 5:45 AM

    Kernon Dillon:
    Yes, you're absolutely right, and like I wrote in my commit message I have "cache files with extended data" meaning proper header data etc. planned. The start, end etc. time buttons will then be gone as the data can be read straight from the files. The current way is just a temporary solution since cache files are now just "dumb" lists of floats. The code for proper header containing cache files will take some time to figure out properly so I thought it best to give you guys at least something in the mean time :). Basically though if for example all particles in your simulation data are born (or have a well defined location) from the very beginning of the simulation then both start and end times are the same (frame 1 I guess) and all you need to set is the particle life time which in this case will be the duration of the simulation in frames.

    ReplyDelete
  3. UnknownJuly 23, 2009 at 9:40 AM

    This is awesome! I'm really looking forward to that feature as I am very interessted in programming, too and I already experimented with some own particle algorithms. So the particle order in the file defines the order in which they are emitted?

    ReplyDelete
  4. jahkaJuly 23, 2009 at 2:54 PM

    Daniel:
    Yes, the order in the files is the order of emission and the index number of the particle.

    ReplyDelete
  5. UnknownJuly 31, 2009 at 10:06 PM

    Hey,

    I wonder if you would mind if I introduce a flag to disable interpolation for smoke and cloth to the cache.
    Is there anything I should know of when doing that?

    greetings

    ReplyDelete

Subscribe to: Post Comments (Atom)