External cache

Particle point cache can now be loaded from external files.
- Activated by "external" checkbox in cache panel and giving proper folder path and file name identifier.
- External cache panel has controls for particle emission start, end, lifetime and random lifetime. These should be set according to the external data for correct playback.
- 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 (per second)
	* 4 floats: particle's rotation quaternion
	* 3 floats: particle's angular velocity vector (per second)
	* 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 (extrapolation is not supported).
- Cache file formats with extended (or reduced even) data members are in future plans for easier usage.
- Current code only does particles, don't yet know if it's applicable to cloth or sb.
- Known issue: endianness can't yet be handled in any way.

Other changes:

New hard limits for many particle parameters. Some examples:
- Maximum amount of particles: 10M particles :) And before you all go and crash your Blender trying this out remember that this limit is only for those freaks who really have the machine power to handle it. 10M particles alone take around 2.2 Gb of memory / disk space in saved file and each cached frame takes around 0.5 Gb of memory / disk space depending on cache mode.
	* Known issue: To actually use this many particles they most likely need to be allocated in parts as taking hold of a 2.2Gb chunk of memory at once is probably not ok with any operating system.
- Maximum amount of children: 100k children/particle (1T childparticles here we come :D)
- Kink frequency: -100k to 100k half-rotations (really strange the previous limit was only from zero upwards)
- Path draw steps: 10 (power of 2 remember)
- Path render steps: 20 (power of 2 also!! If over 1M segments doesn't get you smooth paths then I think nothing will!)

1 files changed, 0 insertions, 7 deletions

diff --git a/source/blender/makesdna/DNA_particle_types.h b/source/blender/makesdna/DNA_particle_types.h
index 2d8a186d3f4..3d1dfff61cd 100644
--- a/source/blender/makesdna/DNA_particle_types.h
+++ b/source/blender/makesdna/DNA_particle_types.h
@@ -233,13 +233,6 @@ typedef struct ParticleSystem{				/* note, make sure all (runtime) are NULL's in
 	struct KDTree *tree;					/* used for interactions with self and other systems */
 }ParticleSystem;
 
-/* general particle maximums */
-/* no special why's, just seem reasonable */
-/* changing these (atleast upwards) should not cause any major problems */
-#define MAX_PARTS			100000	/* real particles/system */
-#define MAX_PART_CHILDREN	10000	/* child particles/real particles */
-#define MAX_BOIDNEIGHBOURS	10		/* neigbours considered/boid */
-
 /* part->type */
 /* hair is allways baked static in object/geometry space */
 /* other types (normal particles) are in global space and not static baked */