ObectIDs are unique and the same run to run?

#1 Ahh ok I see calculateCRC function now,
how about this, I'll just calculate the crc based on all the settings, media file name, position and orientation. that should be pretty unique.

#2 Like so:

//NOTE: assumes that 
	//      mFieldData has been initialized and
	//      mObjToWorld has been initialized

   GameConnection * con = dynamic_cast<GameConnection*>(NetConnection::getServerConnection());
   if(!con)
   {
      Con::errorf(ConsoleLogEntry::General, "fxFoliageReplicator:: no game connection");
      return(false);
   }	
   U32 crcValue = con->getMissionCRC();
   crcValue = calculateCRC(&mFieldData, sizeof(mFieldData), crcValue);
   crcValue = calculateCRC(&mObjToWorld, sizeof(mObjToWorld), crcValue);
   return crcValue;

#3 That almost worked, but mFieldData had a StringTable Entry and a Texture Handle which weren't good things to generate a crc from :)

used the individual members other than those two and it's working good now.

#4 Good to see you solved your own problem. Dare I ask what data you're caching? :)

#5 I was making a pass at caching the fxfoliageitems's. first pass is done and caching works fine. but I'm still not skipping past all the work that can be skipped once they are cached. but the cache file sizes are just getting a little too large for my tastse when they get up to 30 and 40 megs 80

#6 Holy crap, what are you caching? 0.o

#7 @Clint: Sounds like you're hitting the point of diminishing returns there. One of the things that needed doing in the replicators was to see how the memory usage for the foliage structures could be reduced. Typical memory sizes were around 15-meg but I'd have to go back and look through the foliage code to see how many foliage items that was. 30-40 megs sounds like an awful lot of items though.

- Melv.

#8 Heh yes, an aweful lot, on the order of ...well..lets see...
my test level has replicators with
FoliageCount = "600000";
FoliageCount = "10000";
FoliageCount = "10000";
FoliageCount = "50000";

not quite that many end up actually being generated but the 600,000 one does generate about 570,000 items. I could probably get away with caching a lot less than I'm actually caching. I suspect that all the collision ray casts and indexing into the lightmaps takes most of the time, but I should test.

hmm actually I have about the same in my main mission, but the biggest one there is only 400,000
still that comes out to around 28megs compressed.

so that's a ton of these:

class fxFoliageItem
{
public:
   Point3F	   Position; ///< the position in worldspace of this item
   Point3F	   UpVector; ///< the up axis for this item, for instance the normal of the terrain
   F32         Width;
   F32         Height;
   F32		   RotationAngle; ///< rotation about the up vector 0 -> 360
   F32		   LeanAmount; ///< ammount we are leaning off of the up vector 
   Point3F	   Ambient; ///< light color to use
   Box3F       FoliageBox; ///< bounding box for item
   bool        Flipped; ///< is the texture flipped horizontally
   F32         SwayPhase; ///< blowing in the wind
   F32         SwayTimeRatio; 
   F32         LightPhase; ///< light variation used with Ambient
   F32         LightTimeRatio; 
   U32         LastFrameSerialID; ///< bookkeeping to not render twice
   F32		   DistanceToViewer;///< cache distance to viewer if sorting
};

I definitely see some things that could be taken out of the cache :)
U32 LastFrameSerialID; ///< bookkeeping to not render twice
F32 DistanceToViewer;///< cache distance to viewer if sorting

I could probably get away with just caching something more like this

class fxFoliageItem
{
public:
   Point3F	   Position; ///< the position in worldspace of this item
   Point3F	   UpVector; ///< the up axis for this item, for instance the normal of the terrain
   Point3F	   Ambient; ///< light color to use
};

which would be a good deal smaller...err a WHOLE lot smaller. But really even with 570,000 items, we're only talking about 3-4 second faster load time with caching...of course it does all add up as you know.

#9 It's a shame we don't have the equivalent of "half" type. That'd save some room with all the Point3F's and the Box3F.

Or do we somewhere? Could do with some fixed-point here.

- Melv.

#10 Any particular reason you need so much grass? Or that you need so much grass in memory all at once? Rather than caching everything all at once it might be better to just dynamically create grass as it moves into view..?

#11

Quote:Any particular reason you need so much grass?

this question is just bursting with humor :)
I have a large field. if you want a large field full of grass using fxfoliage that's just what you have to do.

Quote:Rather than caching everything all at once it might be better to just dynamically create grass as it moves into view..?

yes indeed. I think I would like to have a pool of foliage nodes we could use that the user could limit then as you move arround you would mark some nodes invalid and reuse them for other new nodes coming into view.

#12 It might be better to do that than blow megs and megs of memory on a quadtree you won't use. :)