|
Great news for vehicle and scenery designers: SimuLab now features unique and strong protection of the 3D models. Content development is a time demanding task requiring skill, good eye for proportion and experience in representing as much detail as possible with as low polygons as possible. The development cost of the assets is high in any game production. Now what about SimuLab? It's free and open source, why bother with protection? While program as such is free and many vehicles will be provided by default, the aircraft designers from T4T team i was talking to, pointed me to the content protection issue. While working hard for providing high quality add-on to their favored sims, these people want to see the vehicles they produce and offer for free to be protected from ripping and abuse: inclusion in commercial bundles, release for other games and without credits to the copyright holders. How it works:
Right now SimuLab accepts 2 well known CAD formats: COLLADA 1.4.1 *.dae and 3DS Max *.3ds files as input. Both importers there provided as open source libraries, I just integrated them into the SL environment. Both formats are well know and supported by exporting tools by almost any CAD software package. The content protector injects on the fly its listener code into the 3D engine to intercept all API calls and all the data loader pass to the engine. Injected code dumps full API access history including object creation, public method call, call parameters and of course the data: vertices, UV coordinates, animation sequences (to come later). The intercepted API calls are then directed to the powerful reflector, which "protocols" the model creation process on the API level. Due to Java compiler limitations, the life data has to be removed from the code scope and stored in a separate file. The result of the process is a generated java class file filled with program statments required to visualize the model in the simulator. The data is stored in disordered random array and stored on disk as data file. This file has no structure, no order and no logic. The code file holds all the threads needed to retrieve the model data from the file. In the next step, the regular Java compiler comes into play and produces java byte code from the source file. The model is no more a separate file to be read by the program, it is part of the program. Java byte code can be decompiled giving interested auditory the generated source code required to read the model. The code file is almost useless as such, because it doesn't correspond to any known CAD file format. In the last step, the java byte code gets loaded by the Excelsior JET virtual machine, which produces natively compiled "code cache" from the class. This final step cannot be reverted. So the result of the process is irreversible piece of program code + data file with unique data structure only understood by this code module.
 |
