Continuing the discussion from Components VS Group:
In the above referenced thread, @DaveR, @slbaumgartner and I have each created similar variations of a single piece of grouped (via both Group and Component) geometry and arrags of each variation - then compared the resulting file sizes - with significant differences!
This has aroused my curiosity - I’d like to get some idea of the structure of a .skp file.
Is it documented anywhere?
No. It is proprietary and has never been documented publicly.
While the file format is proprietary, the C API could give an inkling for how the file is organized. (The intro page contains a file read example.)
I wonder if a program is already available to dump a *.skp file in a textual format, be it plaintext or structured, e.g. YAML.
For what purpose? I have the beginnings of something which I use to help me verify test my contributions to Tommy’s library. Attached is a sample output.
model.txt (4.7 KB)
I think it could be useful to, e.g., verify contributions to sombeody’s library 
or, as @sjdorst asked, inspect group and DC attributes. If you meant specifically the YAML aspect, I mentioned that simply because of ready-made library support for reasonably human-readable formatting of structured data.
Your example is quite nicely formatted. To address the original request, can your code show the model entities’ attributes yet (short of entire geometry) and would you be able to share it?
I would quibble that the C SDK can provide valuable information about what the model contains and how the model is organized, but doesn’t tell you much about how the file itself is structured or how the model contents are represented and organized in the file (which is what is usually meant by “format”).
But given a means to dump the model contents, what other than curiosity would require knowledge of the physical format of the file?
For myself, I’m interested in understanding the file size differences between the 7 files I created as an experiment in the Components VS Group post from which I started (by replying as new topic) this topic.
My interest is, for the most part, simple curiosity. I have no intention of trying to parse a .skp file from outside SketchUp (or Layout). Nor do I create models complex enough that file sizes become problematic.
I anticipate that it might inform future answers on this forum to questions that come down to: “Which should I use: groups or components?” They seem to pop up every 4-6 weeks in some form.
For others? It wouldn’t surprise me if a few forum readers have ideas for great companion programs - NOT implementable (easily) either within SketchUp (through a ruby extension) or externally (through the C API). For those people, available documentation of the structure of a SketchUp file might tip the balance of their “Should I do this?” question from No to Yes - or vice versa! As there are (I think) non-Trimble programs that can read .skp files, I assume that such documentation exists, but (perhaps) only after negotiating with Trimble and signing non-disclosure agreements. This hurdle (negotiation/non-disclosure) is more than I, as an individual, would like to jump before I decide to proceed further with my idea.
Yes and yes, including all geometry - I planned on putting online but just haven’t got around to it yet. I’ll let you know when I do. Like I said, it’s mainly for quickly inspecting a model for testing another library; the output is only mildly interesting otherwise. It gives no insight to the .skp format, but neither does the API functions which is the expectation of a good API.
Why? They could read .skp files using the C SDK without documentation of the file format.
As I have no interest in doing this, I actually don’t know! That’s why I included “(I think)” and “assume” in my post! It wouldn’t surprise me if a 3rd party developer, having tried to do what they need using the C SDK, find that it wasn’t sufficient and managed to negotiate (with Trimble) access to the actual file format.
Can you distill that thread into a brief overview? What you observe and what you expected?
Original poster from that thread wondered about file sizes for a single group and a single component - both containing identical geometry. Also wondered what happens if group/component copied in large numbers.
@DaveR reported experiment with single “pin”, the same pin grouped then arrayed, and the same pin converted to component then arrayed.
I expanded experiments as follow:
3 more files created by opening each of the above 3 files, created total of 100 pins by copying, then saving as separate files.
One more file created by using the saved pin as a component, but using DC to allow it to copy itself for a total of 100 pins, then saving as separate file.
While @DaveR and I didn’t start with the same geometry, we nonetheless expected similar relative file size results - and that was NOT the result!
We speculated a bit to try to account for the differences, then I decided to split off one of the speculations to this thread.
There is actually no specific “speculation” mentioned in this thread’s OP, which is as it should be, because this thread is about the SKP internal file format.
I answered the speculations in that thread where those discussions should remain.
(Thomas is taking this thread off-topic here.)
Back to file format …
A few general tidbits:
SKP is a container format (that can hold other objects in addition to SKP objects.)
Windows binary formats that hold other objects often use OLE data structures.
The MS Visual C Runtime libraries have functions to assist with these kinds of files.
(You can read about these on the Microsoft websites Technet, MSDN, Windows SDK, etc.)
In the SketchUp Ruby API documentation, you’ll find quite a few classes with plural names.
These represent C-side collection objects. You can assume that a SKP file will have a section for most of these data collections (for model objects) in addition to the main “entities” collection.
The file will also have all the options properties you see in the Model Info dialog panels.
It would surprise me however. Many of the end users of the C SDK are other CAD / modeling software providers who know how time consuming and difficult it is to write an API to read complex binary datafiles. They do it for their own software’s file types. They’re really not interested in hacking another company’s file format. (They’ve actually been here in this very forum, asking for features and functions to be added to the existing C SDK.)
Anything they’d do to hack the SKP format would be very fragile as the format seems to change each year. So the smart thing to do is to use the free provided C SDK to access binary SKP files and their internal data.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.