Trunk nightly

[another_commander]

But wreckage could be a problem because it comes in random sizes.

I thought that the wreckage generated randomly by the game itself did not end up in the cache (regardless of the message generated by the test build), but it seems that this is not the case. I have an idea or two on how to force non-inclusion of game generated auto-scaled wreckage in the cache, but it may have to wait for a little due to RL (always gets in the way, doesn't it?).

Edit: Just to have it somewhere till I manage to continue getting on with it, this is the patch as it stands so far:

Code: Select all

diff --git a/src/Core/OOMesh.h b/src/Core/OOMesh.h
index 2a28279..3705a3c 100644
--- a/src/Core/OOMesh.h
+++ b/src/Core/OOMesh.h
@@ -98,6 +98,7 @@ typedef struct
 	OOMeshFaceCount			faceCount;
 	
 	NSString				*baseFile;
+	NSString				*baseFileCacheRef;
 	
 	Vector					*_vertices;
 	Vector					*_normals;
diff --git a/src/Core/OOMesh.m b/src/Core/OOMesh.m
index dc3ec97..d8f4f5f 100644
--- a/src/Core/OOMesh.m
+++ b/src/Core/OOMesh.m
@@ -286,6 +286,7 @@ static BOOL IsPerVertexNormalMode(OOMeshNormalMode mode)
 	if (self == nil)  return nil;
 	
 	baseFile = @"No Model";
+	baseFileCacheRef = @"No Model-0.000";
 #if OO_MULTITEXTURE
 	_textureUnitCount = NSNotFound;
 #endif
@@ -302,6 +303,7 @@ static BOOL IsPerVertexNormalMode(OOMeshNormalMode mode)
 {
 	unsigned				i;
 	
+	DESTROY(baseFileCacheRef);
 	DESTROY(baseFile);
 	DESTROY(octree);
 	
@@ -652,7 +654,8 @@ static NSString *NormalModeDescription(OOMeshNormalMode mode)
 {
 	if (octree == nil)
 	{
-		octree = [[OOCacheManager octreeForModel:baseFile] retain];
+		OOLog(@"octree.cache.read", @"Trying to read octree for mesh %@ from cache.", baseFileCacheRef);
+		octree = [[OOCacheManager octreeForModel:baseFileCacheRef] retain];
 		if (octree == nil)
 		{
 			NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
@@ -671,7 +674,8 @@ static NSString *NormalModeDescription(OOMeshNormalMode mode)
 			
 			octree = [converter findOctreeToDepth:[self octreeDepth]];
 			[octree retain];
-			[OOCacheManager setOctree:octree forModel:baseFile];
+			OOLog(@"octree.cache.write", @"Writing octree for mesh %@ in cache.", baseFileCacheRef);
+			[OOCacheManager setOctree:octree forModel:baseFileCacheRef];
 			
 			[pool release];
 		}
@@ -869,6 +873,7 @@ shaderBindingTarget:(id<OOWeakReferenceSupport>)target
 		PROFILE(@"finished calculateBoundingVolumes (again\?\?)");
 		
 		baseFile = [name copy];
+		baseFileCacheRef = [[NSString stringWithFormat:@"%@-%.3f", baseFile, scale] copy];
 		
 		/*	New in r3033: save the material-defining parameters here so we
 			can rebind the materials at any time.
@@ -917,6 +922,7 @@ shaderBindingTarget:(id<OOWeakReferenceSupport>)target
 	if (result != nil)
 	{
 		[result->baseFile retain];
+		[result->baseFileCacheRef retain];
 		[result->octree retain];
 		[result->_retainedObjects retain];
 		[result->_materialDict retain];
@@ -1154,7 +1160,7 @@ shaderBindingTarget:(id<OOWeakReferenceSupport>)target
 	
 	if (!using_preloaded)
 	{
-		OOLog(@"mesh.load.uncached", @"Mesh \"%@\" is not in cache, loading.", filename);
+		OOLog(@"mesh.load.uncached", @"Mesh \"%@\" is not in cache, loading ( %@ ).", filename, cacheKey);
 		
 		NSCharacterSet	*whitespaceCharSet = [NSCharacterSet whitespaceCharacterSet];
 		NSCharacterSet	*whitespaceAndNewlineCharSet = [NSCharacterSet whitespaceAndNewlineCharacterSet];
@@ -2004,6 +2010,7 @@ static float FaceAreaCorrect(GLuint *vertIndices, Vector *vertices)
 	[self calculateBoundingVolumes];
 	DESTROY(octree);
 	DESTROY(baseFile);	// Avoid octree cache.
+	DESTROY(baseFileCacheRef);
 }

[another_commander]

Second cache test build, this time based on current trunk (10ca9e2) is up. Download from
https://drive.google.com/file/d/0BwG6R5 ... sp=sharing

This build does not generate log messages, but creates the cache in text, human readable form instead. This way the cache can be examined and its contents verified. This build will not write to the cache any octree data about internally and randomly generated wreckage, saving space for octree data that have more chance of getting cache hits. Please test and let us know in case you notice anything funny. Note that apparently some model mesh data for the internally generated wreckages appears to be written in the cache, but this is not related to the test here, we are only testing octrees.

To force the game to flush its cache data to disk so that it can be viewed, make sure to dock at a station before you quit. Then you can check the cahce, saved under oolite.app\GNUstep\Library\Caches\org.aegidian.oolite\Oolite-cache.plist to make sure that no wreckage with scales other than 1.000 exist within. You will need to check the data under the "octrees" key of Oolite_cache.plist.

One other check that you can do if you have the debug console runnning, is to visually confirm the octree data form. To activate visualization of octrees. run the game under the debug console and execute console.debugFlags = 0x80. Look out for any unusual octrees appearance. You can refer to the example below for what a 64x enlarged alloy looks like with its octree display switched on.

As always, please check also that the game still plays normally and no performance hits are observed. Also, shift+restart before testing so that the cache can be refreshed and written in its readable format. Thanks for your testing efforts and time.

[Cody]

"Patterning [12] giraffes",

<chortles>

[Fritz]

Just to check: I do have many entries for wreckage with several scales under the OOMesh key (but not under the octrees key). Is that ok?

"wreck2.dat:0:0.000" seems strange though. And I wonder if something as small as "wreck2.dat:0:0.001" or "wreck2.dat:0:0.002" is worth having 38 faces.

[another_commander]

It is "kind of" normal. Mesh data for generated wreckages have been going in the cache for quite a while now and we just noticed because we are investigating the octrees problem. They don't hurt anyone, but I don't think it helps anyone having them there either. The primary objective of this exercise is to resolve the incorrect octrees problem and as long as you see only wreckage entries with scale of 1.000 under octrees, we should be OK. But now that we know that the cache gets also wreckage mesh data that is not needed, I can have a look at not including them too.

[another_commander]

One more test exe is up, hopefully this is The One: https://drive.google.com/file/d/0BwG6R5 ... sp=sharing

This one should not be writing to the cache any internally generated wreckage data, be it mesh or octree. Everything else, including deliberately rescaled wreckage models, should be going in and behave correctly.

If this one goes well, we could maybe start the process of merging the fix into the core.

[Cody]

Again, no performance hit (that I can detect).

[Fritz]

No problems so far.

[Cody]

What stops a recently-launched offender trader from jumping out when there's a Viper on its six? I see this far too often - well clear of the station, yet will not jump!

[Norby]

I get (0,0,0) in PS.weaponPositionForward so the laser fire from wrong position if I set this in shipdata (live example from ASP SG):

Code: Select all

weapon_position_forward = ("0.0 -2.26444 65.1456");

No problem without brackets but I think it could be a source of OXP bugs with multiple lasers if the bracketed form is not allowed for single positions.

[Norby]

Are you sure?

(Derelict ship still send curses.)

[Cody]

Something slightly odd about this contract's list number: listing and detail - had me confused, anyway.

[Cody]

It seems that whenever there are eleven (or more) parcel contracts on offer, #3 on the list becomes 11 of 11 on the details page.

[another_commander]

Thanks, fixed. Contrary to the norm of the bugs found these days, this one was the result of the lack of copy/paste where it was needed.

[Cody]

No more confusion - thanks!