Bumping this.
K, I'm on a mission. I'm totally over reading all the helpful hints on 3d modelling that are strewn around this site, because without meaning to be rude they all seem to come down to one thing: "Get yerself a hex editor and find things by trial and error".
Eveyone knows there's lots of interesting stuff in them thar files, but nobody seems to know what is really in there or how to interpret it. Consequently, every time somebody wants to do something they have to walk into a dark room without a torch.
So, I'm going to start with bogies. Bogies are great, because they are probably the simplest elements in any .3dp file (they are just one or two squares). This means they are going to be the simplest to understand. They also contain all the information required to start understanding more complex files.
For instance, take the basic two wheels on the front truck of a Berkshire. These are called by two separate .3dp files, but the only difference between them is that the wheel is flipped from one side to the other. That means the only dfferences in the code will tell you how to do this.
Or take the driving wheels. The rear 6 of these all call the same area of the .tga image, but the pairs have different positioning along the loco. That means the only differences between the files will tell you how to reposition an element along the loco.
What about the first driver? It calls a different section of the image, that is over to the left of the others. You see where I'm going with this? We don't need to stumble around in the dark so much. There is a mapping system here. Once it can be understood for the simplest elements, it should be possible to extrapolate it to more complex elements.
Everyone wants to start with the most complex elements (entire locomotives) without understanding the simplest ones. No wonder it's been a nightmare. It's only basic three-dimensional geometry, guys. It's just that the format it is presented in is rather hard to digest. We need to make it digestible if we want to see any more customisation, because otherwise nobody will bother.
==========================================================================
The most useful stuff I have seen so far is on WP&P's site (yes, I have read PJ's and Milo's notes too).
http://wpandp.com/CarModHowTo.html
3DP FILE EDITING
Notes on the 3DP file structure compiled by PJay, as shared with Bombardiere (Kimmo Jaske) and WPandP (Michael Rountree), edited by Michael Rountree.
3DP files
4 bytes : "3DPF" = bytes: 51 68 80 70
4 bytes : 04 00 01 00
4 bytes : "3DMD" - bytes: 51 68 77 68
4 bytes : int: number of instances
3*4 bytes : float: center X, Y, Z
First twelve bytes are just the file header, and are not relevant to modelling. The next part is where it starts getting interesting:
4 bytes : int: number of instances.
Ok, that's great as far as it goes, but it suffers from a common problem, namely that it was written by somebody who knew what they meant, and therefore assumed that everyone else would know what they meant too.
Number of instances of what? Aardvarks? Ice cream? Watermelon sandwiches with pickles on top? Something else? And anyway, how does this relate to the price of eggs in China, and what use is it to anyone who wants to do some loco modelling?
Does anyone know the answer to this? It'd be handy to get it down in print for everyone.
--------------------------------------------
Next we have this:
3*4 bytes : float: center X, Y, Z.
Simple enough, but why four bytes for each coordinate? Each byte can have a value between 0 and 255. What happens when the next byte comes into play? Presumably it just extends the value in the first byte, such that 00 00 00 FF would be 255 in decimal, while 00 00 01 FF would be 511 in decimal. Is this actually how it works? If yes, let's say so, so that anyone can understand it. If no, then how does it work?
Also, if this is how it works, then the maximum value would be FF FF FF FF, which would be something over 4 billion in decimal. That's an extremely high value for a coordinate system, and honestly I can't see any point in allowing values that high. Using three bytes should be more than enough, so why are there four? Does anyone know?
Also, these values have to be signed, so that they can have positive or negative values (for instance, right and left wheels will need this). Is that indicated by using either 0 or 1 on the highest level byte, such that 00 00 00 FF would be 255, and 10 00 00 FF would be -255? If yes, can we please have this clearly stated, so that beginners can actually understand how the system works? If no, how does it work?
--------------------------------------------
Regarding hex editors, I think
HxD is a better choice than the XVI32 that is recommended in the TM dev kit, simply because HxD allows unlimited undo (useful for any editing on any code file), and also allows comparing two different files side by side (a la WinMerge, and similar apps). The compare feature is going to be very useful for mapping how changes work. As far as I can tell, XVI32 doesn't offer either of these features.