senoutouya / recastnavigation

Automatically exported from code.google.com/p/recastnavigation
zlib License
0 stars 0 forks source link

serialize format change again? #148

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1.update to  r250,load geom, build and save mesh
2.update to r254, load geom, load mesh

What is the expected output? What do you see instead?
the loader failed, and i check and find out that the deserializing failed, 
seems that the format has changed...
well, since our project have work for a long time, and lots of nav mesh has 
been builded and saved. update every nav mesh while update the src code to the 
latest version is somehow a boring thing....

What version of the product are you using? On what operating system?

Please provide any additional information below.

Original issue reported on code.google.com by zhibin.l...@gmail.com on 23 Nov 2010 at 3:44

GoogleCodeExporter commented 9 years ago
Yes the Detour format changed in R252 
http://code.google.com/p/recastnavigation/source/detail?r=252

I try to change the format as little as possible, but sometimes it needs to be 
done.

If it is too much trouble for you regen the data, you can undo R252 quite 
easily and revert the version number. Check the diffs for DetourNavMesh.h/cpp 
and DetourNavMeshBuilder.h/cpp

Original comment by memono...@gmail.com on 23 Nov 2010 at 6:29

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
however i would to update the code to fix the bug 144, so what should i do....

Original comment by zhibin.l...@gmail.com on 23 Nov 2010 at 9:25

GoogleCodeExporter commented 9 years ago
Bug 144 touches only Recast, so it is safe to keep R250 and only apply the 
changes in R253 over it.

I'm not very good using SVN, so I would probably just sync to R253, copy 
RecastArea.cpp and RecastRegion.cpp aside, sync back to R250, and copy 
aforementioned files over the existing ones.

Sorry for the trouble. Do you have some ideas how to handle file format changes 
in the future? The fact is that it will change. I hope to change it as little 
as possible, though.

Original comment by memono...@gmail.com on 23 Nov 2010 at 9:35

GoogleCodeExporter commented 9 years ago
if it is only change of format, the data itself is still valid, you can keep a 
set of loaders of different version. for example, Load250(), Load253(), or 
LoadVersion1(),LoadVersion2()...and so on. In the Load() function, use a 
switch(version){} way to load differnt version.
However, if the data itself is not valid anymore....OK, we just rebuild it.
AnyWay, thanks again for your hardwork

Original comment by zhibin.l...@gmail.com on 23 Nov 2010 at 11:00

GoogleCodeExporter commented 9 years ago
To make things efficient, the data stored for Detour is used as is, that is, 
there is no layer to translate the data read from disc to the one that is used 
in memory. The data that is loaded to memory is used directly. It makes it 
really fast to load, but really hard to load old versions of data.

I could try to write conversion code between different versions, but that would 
mean huge amounts of extra work for me.

Original comment by memono...@gmail.com on 23 Nov 2010 at 11:23

GoogleCodeExporter commented 9 years ago

Original comment by memono...@gmail.com on 26 Nov 2010 at 12:50